<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 12, 2016 at 10:17 AM, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On Mon, Dec 12, 2016 at 09:52:04AM +0530, Krutika Dhananjay wrote:<br>
> With this fix, the user does not need to worry about when to enable/disable<br>
> the option -<br>
> the CLI command itself performs the necessary checks before allowing the<br>
> "enable" command to proceed.<br>
> What are those checks?<br>
> * Whether heal is already needed on the volume<br>
> * Whether any of the replicas is down<br>
> In both of the cases, the command will be failed since AFR will be<br>
> switching from creating heal indices (markers<br>
> for files that need heal) under .glusterfs/indices/xattrop to creating them<br>
> under .glusterfs/indices/entry-<wbr>changes.<br>
> The moment this switch happens, self-heal-daemon will cease to crawl the<br>
> entire directory if a directory needs heal<br>
> and instead looks for exact names under a directory that need heal under<br>
> .glusterfs/indices/entry-<wbr>changes. This<br>
> might cause self-heal to miss healing some entries (because before the<br>
> switch directories already needing heal won't<br>
> have any indices under .glusterfs/indices/entry-<wbr>changes) and mistakenly<br>
> unset the pending heal xattrs even though<br>
> the individual replicas are not in sync.<br>
><br>
> When should they enable the option? - When they want to use the feature ;)<br>
> - which is useful<br>
> for faster self-healing in use cases with large number of files under a<br>
> single directory.<br>
> For example, it is useful in VM use cases with smaller shard sizes, given<br>
> that all shards are created<br>
> under a single directory ".shard". When a shard is created while a replica<br>
> was down, once it is back up,<br>
> self-heal due to its maintaining granular indices will know exactly which<br>
> shard to recreate on the sync as<br>
> opposed to crawling the entire .shard directory to find out the same<br>
> information.<br>
><br>
> When should they disable the option? - When they don't like the feature or<br>
> if/when a bug is found in it,<br>
<br>
</div></div>Thanks for the details!<br>
<span class="gmail-"><br>
> ... speaking of which, can we wait till <a href="http://review.gluster.org/#/c/16075/" rel="noreferrer" target="_blank">http://review.gluster.org/#/c/<wbr>16075/</a><br>
> is also merged into 3.8 before making<br>
> the release? Although the bug is in AFR core, the likelihood of hitting the<br>
> bug is more with granular entry heal<br>
> than without it. And I know of at least 3 users who are using the feature<br>
> already on their production system.<br>
> Otherwise we might have to wait one more month for the fix to be taken in,<br>
> which is quite late IMO.<br>
<br>
</span>I do not see a cloned bug for 3.8.7 yet? Could you clone the bug for<br>
mainline and add "glusterfs-3.8.7" in the blocks field of the new BZ?<br></blockquote><div><br></div><div>Thank you! Here it is - <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1403646">https://bugzilla.redhat.com/show_bug.cgi?id=1403646</a><br><br></div><div>-Krutika<br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
Niels<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
><br>
> -Krutika<br>
><br>
> On Sun, Dec 11, 2016 at 10:23 PM, Niels de Vos <<a href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>> wrote:<br>
><br>
> > 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'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>
> ><br>
</div></div></blockquote></div><br></div></div>