----- Original Message -----
> From: "Lindsay Mathieson" <lindsay.mathieson at gmail.com>
> To: "Krutika Dhananjay" <kdhananj at redhat.com>
> Cc: "Gluster Devel" <gluster-devel at gluster.org>,
"gluster-users"
> <gluster-users at gluster.org>
> Sent: Wednesday, December 16, 2015 6:56:03 AM
> Subject: Re: Sharding - what next?
> Hi, late reply again ...
> On 10/12/2015 5:33 PM, Krutika Dhananjay wrote:
> > There is a 'heal-info summary' command that is under review,
written by
> > Mohammed Ashiq @ http://review.gluster.org/#/c/12154/3 which prints
the
> > number of files that are yet to be healed.
>
> > It could perhaps be enhanced to print files in split-brain and also
files
> > which are possibly being healed. Note that these counts are printed
per
> > brick.
>
> > It does not print a single list of counts with aggregated values.
Would
> > that
> > be something you would consider useful?
>
> Very much so, that would be perfect.
> I can get close to this just with the following
> gluster volume heal datastore1 info | grep 'Brick\|Number'
> And if one is feeling fancy or just wants to keep an eye on progress
> watch "gluster volume heal datastore1 info | grep
'Brick\|Number'"
> though of course this runs afoul of the heal info delay.
I guess I did not make myself clear. Apologies. I meant to say that printing a
single list of counts aggregated
from all bricks can be tricky and is susceptible to the possibility of same
entry getting counted multiple times
if the inode needs a heal on multiple bricks. Eliminating such duplicates would
be rather difficult.
Or, we could have a sub-command of heal-info dump all the file paths/gfids that
need heal from all bricks and
you could pipe the output to 'sort | uniq | wc -l' to eliminate
duplicates. Would that be OK? :)
-Krutika
> > > Also, it would be great if the heal info command could return
faster,
> > > sometimes it takes over a minute.
> >
>
> > Yeah, I think part of the problem could be eager-lock feature which is
> > causing the GlusterFS client process to not relinquish the network
lock on
> > the file soon enough, causing the heal info utility to be blocked for
> > longer
> > duration.
>
> > There is an enhancement Anuradha Talur is working on where heal-info
would
> > do
> > away with taking locks altogether. Once that is in place, heal-info
should
> > return faster.
>
> Excellent, I look fwd to that. Even if removing the locks results in the
> occasional inaccurate cout, I don't think that would mattter - From my
POV
> its an indicator, not a absolute.
> Thanks,
> --
> Lindsay Mathieson
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20151216/4ff36d4e/attachment.html>