Follow these steps: step-1: Take a backup of the file. step-2: On one of the bricks execute, setfattr -n trusted.afr.488_1152-client-0 -v 0x000000010000000000000000 <file-path> After the steps above are done on both the files step-3: gluster volume heal <volname> - This will trigger the heal and things should be good now. step-4: Check the md5sums on the files are same with the backups we took in step-1. (This step is not really required but I am paranoid) step-5: Give pranith logs :-) Pranith. ----- Original Message ----- > From: "Nux!" <nux at li.nux.ro> > To: "Pranith Kumar Karampuri" <pkarampu at redhat.com> > Cc: "Gluster Users" <gluster-users at gluster.org> > Sent: Monday, August 5, 2013 3:19:41 PM > Subject: Re: No active sinks for performing self-heal on file > > On 05.08.2013 10:38, Pranith Kumar Karampuri wrote: > > With only one sever reboot it should not lead to this issue. Will it > > be possible to send the logs so that I can root cause the issue. What > > is the version of glusterfs? > > Are you sure the file is not in active use at the time of getfattr > > command execution? > > > > Check md5sums of the files on both the bricks when no operations are > > in progress on the file. If they are same we can erase these changelog > > xattrs and things should be back to normal. > > If md5sums are different then one needs to figure out which files are > > more recent and edit the xattrs so that it is healed in the right > > direction. I can help you with this on IRC. my nick on irc is > > pranithk. > > I will be online in 30 minutes. > > > > But It is still not clear how the files ended up in this situation. > > How many files are in this status. Logs would be helpful. > > > > Hello Pranith, > > Only 2 files appear in the logs over and over again: > > gfid:4ab40ffe-29d8-4e90-9f03-e7a61e92ce4c > gfid:c525c671-9855-4d3b-b1ab-dbc9fc7022cf > > getfattr -d -m . -e hex > /bricks/488_1152/.glusterfs/c5/25/c525c671-9855-4d3b-b1ab-dbc9fc7022cf > getfattr: Removing leading '/' from absolute path names > # file: > bricks/488_1152/.glusterfs/c5/25/c525c671-9855-4d3b-b1ab-dbc9fc7022cf > trusted.afr.488_1152-client-0=0x000000010000000000000000 > trusted.afr.488_1152-client-1=0x000000010000000000000000 > trusted.gfid=0xc525c67198554d3bb1abdbc9fc7022cf > trusted.glusterfs.quota.2c056f93-fe6d-4927-8423-57d6ae80b9fb.contri=0x0000000000109000 > > getfattr -d -m . -e hex > /bricks/488_1152/.glusterfs/4a/b4/4ab40ffe-29d8-4e90-9f03-e7a61e92ce4c > getfattr: Removing leading '/' from absolute path names > # file: > bricks/488_1152/.glusterfs/4a/b4/4ab40ffe-29d8-4e90-9f03-e7a61e92ce4c > trusted.afr.488_1152-client-0=0x000000010000000000000000 > trusted.afr.488_1152-client-1=0x000000010000000000000000 > trusted.gfid=0x4ab40ffe29d84e909f03e7a61e92ce4c > trusted.glusterfs.quota.2c056f93-fe6d-4927-8423-57d6ae80b9fb.contri=0x00000000000f3600 > > > I have checked both their md5 sums and are identical on all bricks, > though I can't be 100% sure the files are not in use by the customer. > How do I go about erasing those changelog xattrs? > > I can provide full logs, but this has been happening for a while and I > imagine the logs are quite huge by now, let me know if you still need > them. > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro >
