[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.
Thanks,
--
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