----- Original Message ----- > From: "Lindsay Mathieson" <[email protected]> > To: "Krutika Dhananjay" <[email protected]> > Cc: "Gluster Devel" <[email protected]>, "gluster-users" > <[email protected]> > 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
_______________________________________________ Gluster-devel mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-devel
