[Gluster-users] Re. Is there a way to force a brick in a replica set to automatically self heal after it goes down and comes back up?

[Dan Bretherton]

> On 10/24/2012 02:20 PM, Kushnir, Michael (NIH/NLM/LHC) [C] wrote:
> >/  I am thinking of a scenario where a brick #2 in two-brick a replica set goes
> />/  down and then comes back up. It will be inconsistent with brick #1. From what I
> />/  understand, missing and changed files are not replicated until a user reads or
> />/  writes to those files. Is there a way to make the brick auto-heal when it comes
> />/  back up?
> /
> In 3.3 onward, there is a feature called "proactive self-heal" which will
> automatically start repair in such cases.  It's also more efficient than
> relying on find|stat from a client, though the client driven self-heal is still
> there as a belt-and-suspenders kind of thing.
Am I right in thinking that self-heal is also supposed to take place 
when files are accessed by users?  I found recently that this does not 
happen for files that users don't have write access to.  Last week a 
user kept reporting lots of I/O errors on files in various directories, 
but every time I checked the files as root there were no errors.  A lot 
of xattr errors had been caused by problems I reported in other threads, 
and I explained to the user that there was a self-heal process going on 
in the background.  I also told him that if he encountered files that 
had not yet been healed, a self-heal would be triggered on demand.   As 
the user became progressively more annoyed during the week I looked into 
it more carefully, and I realised that the self-heal was only being 
triggered when I tried to access the files as root, or as a user with 
write access to the files.  Is this expected behaviour?  It's certainly 
not what I expected or wanted.  I healed the users' files using a 
GlusterFS 3.2 style find|stat, but that's not something I thought would 
be necessary in version 3.3.

-Dan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20121105/bfb2acb1/attachment.html>