[Gluster-Maintainers] glusterfs-3.8: User understandable release note needed for new CLI command for ESH

[Niels de Vos]

On Mon, Dec 12, 2016 at 09:52:04AM +0530, Krutika Dhananjay wrote:
> With this fix, the user does not need to worry about when to enable/disable
> the option -
> the CLI command itself performs the necessary checks before allowing the
> "enable" command to proceed.
> What are those checks?
> * Whether heal is already needed on the volume
> * Whether any of the replicas is down
> In both of the cases, the command will be failed since AFR will be
> switching from creating heal indices (markers
> for files that need heal) under .glusterfs/indices/xattrop to creating them
> under .glusterfs/indices/entry-changes.
> The moment this switch happens, self-heal-daemon will cease to crawl the
> entire directory if a directory needs heal
> and instead looks for exact names under a directory that need heal under
> .glusterfs/indices/entry-changes. This
> might cause self-heal to miss healing some entries (because before the
> switch directories already needing heal won't
> have any indices under .glusterfs/indices/entry-changes) and mistakenly
> unset the pending heal xattrs even though
> the individual replicas are not in sync.
> 
> When should they enable the option? - When they want to use the feature ;)
> - which is useful
> for faster self-healing in use cases with large number of files under a
> single directory.
> For example, it is useful in VM use cases with smaller shard sizes, given
> that all shards are created
> under a single directory ".shard". When a shard is created while a replica
> was down, once it is back up,
> self-heal due to its maintaining granular indices will know exactly which
> shard to recreate on the sync as
> opposed to crawling the entire .shard directory to find out the same
> information.
> 
> When should they disable the option? - When they don't like the feature or
> if/when a bug is found in it,

Thanks for the details!

> ... speaking of which, can we wait till http://review.gluster.org/#/c/16075/
> is also merged into 3.8 before making
> the release? Although the bug is in AFR core, the likelihood of hitting the
> bug is more with granular entry heal
> than without it. And I know of at least 3 users who are using the feature
> already on their production system.
> Otherwise we might have to wait one more month for the fix to be taken in,
> which is quite late IMO.

I do not see a cloned bug for 3.8.7 yet? Could you clone the bug for
mainline and add "glusterfs-3.8.7" in the blocks field of the new BZ?

Thanks,
Niels

> 
> -Krutika
> 
> On Sun, Dec 11, 2016 at 10:23 PM, Niels de Vos <ndevos at redhat.com> wrote:
> 
> > Could you please pass me a few lines that are understandable for users
> > so that they know when/if they should enable/disable the new
> > granular-entry-heal option?
> >
> > The bug does not explain a lot, and the commit message is not very user
> > friendly:
> >   https://bugzilla.redhat.com/show_bug.cgi?id=1398501#c4
> >
> > It helps to know what kind of errors/warnings are produced, and what the
> > recommended action is.
> >
> > I'll wait with pushing the release-notes for 3.8.7 until I have more
> > details. This obviously blocks the release as well.
> >
> > Thanks,
> > Niels
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20161212/abc97209/attachment.sig>