Thanks for this additional info. It really helps! If you give me the scenarios I can come up with the script and send it to this user group. So far I have: 1. Different afr on node that was receiving updated 2. Different gfid. Only way is to compare gfid is to run getfattr on every replica node. BTW: I noticed that getfattr <mount>/file also heals. Don't understand why but it does :) On Fri, Mar 11, 2011 at 5:59 PM, Pranith Kumar. Karampuri <pranithk at gluster.com> wrote: > hi Mohit, > ? ? I have sent a patch for the bug you have raised for self-heal not working in one case already. > > For a file, it should have either different extended attributes for client-0/1 (assuming two replica) and same gfid extended attribute. > or different extended attribute for gfid. > example: > pranith @ /mnt/client > 07:24:05 :) $ sudo getfattr -d -m "trusted*" /tmp/1/file1 > getfattr: Removing leading '/' from absolute path names > # file: tmp/1/file1 > trusted.afr.vol-client-0=0sAAAAAAAAAAAAAAAA > trusted.afr.vol-client-1=0sTwAAAgAAAAAAAAAA > trusted.gfid=0s9JoVEu1WQQCykafEGcz74Q== > > pranith @ /mnt/client > 07:24:34 :) $ sudo getfattr -d -m "trusted*" /tmp/2/file1 > getfattr: Removing leading '/' from absolute path names > # file: tmp/2/file1 > trusted.afr.vol-client-0=0sAAAAAAAAAAAAAAAA > trusted.afr.vol-client-1=0sAAAAAAAAAAAAAAAA > trusted.gfid=0s9JoVEu1WQQCykafEGcz74Q== > > After self-heal completes they become: > pranith @ /mnt/client > 07:27:21 :) $ sudo getfattr -d -m "trusted*" /tmp/1/file1 > getfattr: Removing leading '/' from absolute path names > # file: tmp/1/file1 > trusted.afr.vol-client-0=0sAAAAAAAAAAAAAAAA > trusted.afr.vol-client-1=0sAAAAAAAAAAAAAAAA > trusted.gfid=0s9JoVEu1WQQCykafEGcz74Q== > > > pranith @ /mnt/client > 07:27:26 :) $ sudo getfattr -d -m "trusted*" /tmp/2/file1 > getfattr: Removing leading '/' from absolute path names > # file: tmp/2/file1 > trusted.afr.vol-client-0=0sAAAAAAAAAAAAAAAA > trusted.afr.vol-client-1=0sAAAAAAAAAAAAAAAA > trusted.gfid=0s9JoVEu1WQQCykafEGcz74Q== > > Thanks > Pranith. > ----- Original Message ----- > From: "Mohit Anchlia" <mohitanchlia at gmail.com> > To: gluster-users at gluster.org > Sent: Saturday, March 12, 2011 4:31:16 AM > Subject: Re: Self heal doesn't seem to work when file is ? ? ? ?updated > > Can somone from gluster developer community please tell respond how to > find if self heal worked? > > Or better yet how to determine if a file needs to be healed? Please > let me know as this very important aspect. > > On Thu, Mar 10, 2011 at 9:54 AM, William L. Sebok <wls at astro.umd.edu> wrote: >> It also won't work well when the bricks are under use and might be changing. >> >> Bill Sebok ? ? ?Computer Software Manager, Univ. of Maryland, Astronomy >> ? ? ? ?Internet: wls at astro.umd.edu ? ? URL: http://furo.astro.umd.edu/ >> >> On Thu, Mar 10, 2011 at 09:39:44AM -0800, Mohit Anchlia wrote: >>> It doesn't look like a good way of checking when it involves millions >>> of files and something you don't want to run every now and then. I was >>> expecting something from gluster commands to straight away provide >>> that info. Something that can then be monitored continuously. It's >>> very important to have right version of files in production and only >>> gluster knows which were healed. >>> >>> On Thu, Mar 10, 2011 at 1:40 AM, Marcus Bointon >>> <marcus at synchromedia.co.uk> wrote: >>> > On 9 Mar 2011, at 20:08, Mohit Anchlia wrote: >>> > >>> >> Asking my question again since it's very important to know how to find >>> >> out if self healing worked. >>> > >>> > Do an rsync with dry-run option on the back-end stores? They should be identical. >>> > >>> > Marcus >> > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://gluster.org/cgi-bin/mailman/listinfo/gluster-users >
