Re: Hundreds of duplicate files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Should be safe.

Here's what I've done in the past to clean up rogue dht link files (not that yours looked rogue though):

find $brick_root -type f -size 0 -perm 1000 -exec /bin/rm {} \;

On 12/27/2014 11:09 AM, tbenzvi@xxxxxxxxxxxxxxx wrote:
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: Hundreds of duplicate files
From: "Vijay Bellur" <vbellur@xxxxxxxxxx>
Date: 12/27/14 9:12 am
To: tbenzvi@xxxxxxxxxxxxxxx, gluster-users@xxxxxxxxxxx

On 12/27/2014 01:11 PM, tbenzvi@xxxxxxxxxxxxxxx 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@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@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@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@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


_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users

_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users

[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux