<html><body><div style="font-family: garamond,new york,times,serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Lindsay Mathieson" <lindsay.mathieson@gmail.com><br><b>To: </b>"Krutika Dhananjay" <kdhananj@redhat.com><br><b>Cc: </b>"Gluster Devel" <gluster-devel@gluster.org>, "gluster-users" <gluster-users@gluster.org><br><b>Sent: </b>Wednesday, December 16, 2015 6:56:03 AM<br><b>Subject: </b>Re: Sharding - what next?<br><div><br></div>
Hi, late reply again ...<br><br><div class="moz-cite-prefix">On 10/12/2015 5:33 PM, Krutika
Dhananjay wrote:<br></div><blockquote cite="mid:22287928.16775269.1449732814843.JavaMail.zimbra@redhat.com"><div>There is a 'heal-info summary' command that is under review,
written by Mohammed Ashiq @ <a href="http://review.gluster.org/#/c/12154/3" target="_blank">http://review.gluster.org/#/c/12154/3</a>
which prints the number of files that are yet to be healed.<br></div><div>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.</div><div>It does not print a single list of counts with aggregated
values. Would that be something you would consider useful?<br></div></blockquote><br>
Very much so, that would be perfect. <br><br>
I can get close to this just with the following<br><br><tt> gluster volume heal datastore1 info | grep 'Brick\|Number'</tt><br><br><br>
And if one is feeling fancy or just wants to keep an eye on progress<br><br><tt> watch "gluster volume heal datastore1 </tt><tt><tt>info </tt>|
grep 'Brick\|Number'"</tt><br><br>
though of course this runs afoul of the heal info delay.</blockquote><div><br></div><div>I guess I did not make myself clear. Apologies. I meant to say that printing a single list of counts aggregated</div><div>from all bricks can be tricky and is susceptible to the possibility of same entry getting counted multiple times</div><div>if the inode needs a heal on multiple bricks. Eliminating such duplicates would be rather difficult.<br></div><div><br></div><div>Or, we could have a sub-command of heal-info dump all the file paths/gfids that need heal from all bricks and</div><div>you could pipe the output to 'sort | uniq | wc -l' to eliminate duplicates. Would that be OK? :)<br></div><div><br></div><div>-Krutika<br></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br><br><blockquote cite="mid:22287928.16775269.1449732814843.JavaMail.zimbra@redhat.com"><div><br></div><blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br><br><br>
Also, it would be great if the heal info command could return
faster, sometimes it takes over a minute.</blockquote><div>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.<br></div><div>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.<br></div><div><br></div></blockquote><br><br>
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.<br><br>
Thanks,<br><pre class="moz-signature">--
Lindsay Mathieson</pre></blockquote><div><br></div></div></body></html>