<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite">
<pre>On 10/24/2012 02:20 PM, Kushnir, Michael (NIH/NLM/LHC) [C] wrote:
><i> I am thinking of a scenario where a brick #2 in two-brick a replica set goes
</i>><i> down and then comes back up. It will be inconsistent with brick #1. From what I
</i>><i> understand, missing and changed files are not replicated until a user reads or
</i>><i> writes to those files. Is there a way to make the brick auto-heal when it comes
</i>><i> back up?
</i>
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.</pre>
</blockquote>
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.<br>
<br>
-Dan.<br>
<br>
</body>
</html>