[Gluster-users] heal-count vs heal-info and "continual heals"?

[Krutika Dhananjay]

On Tue, Apr 19, 2016 at 5:30 AM, Lindsay Mathieson <
lindsay.mathieson at gmail.com> wrote:

> Is it possible to confirm the following understandings on my part?
>
>
> - heal info shows the list of files with uncommitted writes across the
> bricks that would need heals **if** a brick went down before the write
> was committed.
>

Yes and no. So heal-info reports both files that truly need heal and those
that are currently participating in an uncommitted transaction. The latter
entries are reported as "possible undergoing heal". I believe we are going
to drop the latter category of entries going forward. IIUC Pranith is
working on something that does that. But I will let him confirm that.



>   * additionally it lists files being healed if a heal is in process
>   * writes can be data and metadata.
>
>

> - statics heal-count shows the count of files **actually needing healing**
>

This is correct for the most part. The only remote case where it will not
report pending heals when it is supposed to is if some entries were marked
"dirty" (indicated by the presence of their index under
.glusterfs/indices/dirty). So it only considers count of entries needing
heal in .glusterfs/indices/xattrop but not .glusterfs/indices/dirty.

For what it's worth, I realised that we don't really need to use locks to
examine whether files need heal or not if the entries are under
indices/xattrop. So if there is an entry under .glusterfs/indices/xattrop,
it means it definitely needs heal. Only the entries under
.glusterfs/indices/dirty need careful inspection. This will significantly
enhance heal-info response time. So I will
work on getting this change in, maybe for the next .x release.

-Krutika

>
>
>
>
>
> So its perfectly ok to see files being listed by heal info on a busy
> cluster, so long as they aren't marked as a heal in progress.
>
>
> thanks ,
>
> --
> Lindsay Mathieson
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20160419/be7c450c/attachment.html>