[Gluster-users] Hundreds of duplicate files

tbenzvi at 3vgeomatics.com tbenzvi at 3vgeomatics.com
Sat Dec 27 19:09:24 UTC 2014


Moving the file with linkto attribute worked! Just one copy of the file is retained in the listing and can be read without problems.
I will write a script to remove these rogue link files from the bricks - any risks associated with this?
 
Thanks everyone for your help, of course if anyone could explain how this happened I would love to hear it..
 
Tom
 
--------- Original Message --------- Subject: Re: [Gluster-users] Hundreds of duplicate files
From: "Vijay Bellur" <vbellur at redhat.com>
Date: 12/27/14 9:12 am
To: tbenzvi at 3vgeomatics.com, gluster-users at gluster.org

On 12/27/2014 01:11 PM, tbenzvi at 3vgeomatics.com wrote:
 > Thanks for your continued help Joe.
 > A demonstration of the problem, in this case I was able to open the file
 > in vim (a text file) without any issues, however sometimes duplicated
 > text files open in vim as one line consisting of @ characters, and
 > binary data files can also not be opened correctly for reading.
 > However the duplicate listing is still an issue. Note that Dec 13 was
 > the date of a server crash.
 >
 > [root at jongoo ~]# ll /sar/complete/vancouver/refdem/tif2flt.pro*
 > -rw-rw-r-T 1 parwant users 1712 Dec 13 19:02 tif2flt.pro
 > -rw-rw-r-- 1 parwant users 1712 Jun 17 2010 tif2flt.pro
 >
 > A few minutes later doing the same listing.. sticky bit disappeared and
 > modification date changed
 >
 > [root at jongoo ~]# ll /sar/complete/vancouver/refdem/tif2flt.pro*
 > -rw-rw-r-- 1 parwant users 1712 Jun 17 2010
 > /sar/complete/vancouver/refdem/tif2flt.pro
 > -rw-rw-r-- 1 parwant users 1712 Jun 17 2010
 > /sar/complete/vancouver/refdem/tif2flt.pro
 >
 > [root at jongoo ~]# getfattr -m . -d -e hex
 > /data/glusterfs/safari/brick00/brick/complete/vancouver/refdem/tif2flt.pro
 > getfattr: Removing leading '/' from absolute path names
 > # file:
 > data/glusterfs/safari/brick00/brick/complete/vancouver/refdem/tif2flt.pro
 > system.posix_acl_access=0x0200000001000600ffffffff04000600ffffffff10000600ffffffff20000400ffffffff
 > trusted.SGI_ACL_FILE=0x0000000400000001ffffffff0006000000000004ffffffff0006000000000010ffffffff0006000000000020ffffffff00040000
 > trusted.gfid=0xdfe13dc088bf4a779488ef72f0a879cd
 > trusted.glusterfs.dht.linkto=0x7361666172692d636c69656e742d3300
 >
 > [root at ndovu ~]# getfattr -m . -d -e hex
 > /data/glusterfs/safari/brick03/brick/complete/vancouver/refdem/tif2flt.pro
 > getfattr: Removing leading '/' from absolute path names
 > # file:
 > data/glusterfs/safari/brick03/brick/complete/vancouver/refdem/tif2flt.pro
 > system.posix_acl_access=0x0200000001000600ffffffff04000600ffffffff10000600ffffffff20000400ffffffff
 > trusted.SGI_ACL_FILE=0x0000000400000001ffffffff0006000000000004ffffffff0006000000000010ffffffff0006000000000020ffffffff00040000
 > trusted.gfid=0xdfe13dc088bf4a779488ef72f0a879cd
 >
 
 Is rebalance running on this volume right now? If not, can you please 
 move out the file copy with "trusted.glusterfs.dht.linkto" attribute out 
 of the brick directory 
 (/data/glusterfs/safari/brick00/brick/complete/vancouver/refdem/tif2flt.pro) 
 to an alternate location & check the behavior?
 
 Thanks,
 Vijay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20141227/81f99426/attachment.html>


More information about the Gluster-users mailing list