<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 02/25/2016 08:25 PM, Krutika
Dhananjay wrote:<br>
</div>
<blockquote
cite="mid:805871901.14894730.1456449926915.JavaMail.zimbra@redhat.com"
type="cite">
<div style="font-family: garamond,new york,times,serif; font-size:
12pt; color: #000000">
<div><br>
</div>
<div><br>
</div>
<hr id="zwchr">
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From:
</b>"Kyle Maas" <a class="moz-txt-link-rfc2396E" href="mailto:kyle@virtualinterconnect.com"><kyle@virtualinterconnect.com></a><br>
<b>To: </b><a class="moz-txt-link-abbreviated" href="mailto:gluster-users@gluster.org">gluster-users@gluster.org</a><br>
<b>Sent: </b>Thursday, February 25, 2016 11:36:53 PM<br>
<b>Subject: </b>[Gluster-users] AFR Version used for
self-heal<br>
<div><br>
</div>
How can I tell what AFR version a cluster is using for
self-heal?<br>
<div><br>
</div>
The reason I ask is that I have a two-node replicated 3.7.8
cluster (no<br>
arbiters) which has locking behavior during self-heal which
looks very<br>
similar to that of AFRv1 (only heals one file at a time per
self-heal<br>
daemon, appears to lock the full inode while it's healing it
instead of<br>
just ranges, etc.), but I don't know how I would check the
version to<br>
confirm that suspicion. I've seen mention of needing to
explicitly<br>
enable AFRv2 when upgrading Gluster from an older version, and
this<br>
cluster was one that started at an older Gluster version and
was<br>
upgraded in accordance with the upgrade docs, but I cannot
seem to find<br>
any documentation on enabling newer versions of AFR or even
checking<br>
which one I'm running at. cluster.op-version for this cluster
is<br>
currently at 30603, and both nodes are CentOS 7 running
Gluster 3.7.8.<br>
<div><br>
</div>
Any help would be appreciated. Thanks!</blockquote>
<div><br>
</div>
<div>So if you bring one of the replicas down, create a file,
and check its extended attributes from the backend (`getfattr
-d -m . -e hex
<path-to-the-file-from-the-brick-path-that-is-online`),<br>
</div>
<div>do you see this appearing in the list:<br>
</div>
<div><br>
</div>
<div>trusted.afr.dirty=0x000000000000000000000000</div>
<br>
</div>
</blockquote>
<br>
The cluster I'm having problems with has been around for quite a
while and is very actively used. When this cluster gets out of
sync, a self-heal can take up to 24 hours due to the amount of write
activity. Any test or check which requires triggering a self-heal
is difficult for me to do, so I suspect I will need to try to spin
up a new cluster as a small-scale duplicate of the one I'm having
problems with to be able to try this. As a result, I will need to
get back to you with the results of this experiment.<br>
<br>
Warm Regards,<br>
Kyle Maas<br>
</body>
</html>