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.
_______________________________________________
Gluster-users mailing list
[email protected]
http://supercolony.gluster.org/mailman/listinfo/gluster-users
