[Gluster-devel] Sharding - what next?

Lindsay Mathieson lindsay.mathieson at gmail.com
Wed Dec 16 01:26:03 UTC 2015

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.

>     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.


Lindsay Mathieson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20151216/971f169f/attachment.html>

More information about the Gluster-devel mailing list