<div dir="ltr"><div><div><div><div><div><div><div><div><div>With this fix, the user does not need to worry about when to enable/disable the option -<br></div>the CLI command itself performs the necessary checks before allowing the &quot;enable&quot; command to proceed.<br></div><div>What are those checks?<br></div><div>* Whether heal is already needed on the volume<br></div><div>* Whether any of the replicas is down<br></div><div>In both of the cases, the command will be failed since AFR will be switching from creating heal indices (markers<br></div><div>for files that need heal) under .glusterfs/indices/xattrop to creating them under .glusterfs/indices/entry-changes.<br></div><div>The moment this switch happens, self-heal-daemon will cease to crawl the entire directory if a directory needs heal<br></div><div>and instead looks for exact names under a directory that need heal under .glusterfs/indices/entry-changes. This<br></div><div>might cause self-heal to miss healing some entries (because before the switch directories already needing heal won&#39;t<br></div><div>have any indices under .glusterfs/indices/entry-changes) and mistakenly unset the pending heal xattrs even though<br></div><div>the individual replicas are not in sync.<br></div><div><br></div>When should they enable the option? - When they want to use the feature ;) - which is useful<br></div>for faster self-healing in use cases with large number of files under a single directory.<br></div>For example, it is useful in VM use cases with smaller shard sizes, given that all shards are created<br></div>under a single directory &quot;.shard&quot;. When a shard is created while a replica was down, once it is back up,<br></div>self-heal due to its maintaining granular indices will know exactly which shard to recreate on the sync as<br></div>opposed to crawling the entire .shard directory to find out the same information.<br><br></div>When should they disable the option? - When they don&#39;t like the feature or if/when a bug is found in it,<br></div><div>... speaking of which, can we wait till <a href="http://review.gluster.org/#/c/16075/">http://review.gluster.org/#/c/16075/</a> is also merged into 3.8 before making<br></div><div>the release? Although the bug is in AFR core, the likelihood of hitting the bug is more with granular entry heal<br></div><div>than without it. And I know of at least 3 users who are using the feature already on their production system.<br></div><div>Otherwise we might have to wait one more month for the fix to be taken in, which is quite late IMO.<br></div><div><br></div><div>-Krutika<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 11, 2016 at 10:23 PM, Niels de Vos <span dir="ltr">&lt;<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Could you please pass me a few lines that are understandable for users<br>
so that they know when/if they should enable/disable the new<br>
granular-entry-heal option?<br>
<br>
The bug does not explain a lot, and the commit message is not very user<br>
friendly:<br>
  <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1398501#c4" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/<wbr>show_bug.cgi?id=1398501#c4</a><br>
<br>
It helps to know what kind of errors/warnings are produced, and what the<br>
recommended action is.<br>
<br>
I&#39;ll wait with pushing the release-notes for 3.8.7 until I have more<br>
details. This obviously blocks the release as well.<br>
<br>
Thanks,<br>
Niels<br>
</blockquote></div><br></div>