----- Original Message ----- > From: "Jeff Darcy" <jdarcy@xxxxxxxxxx> > To: "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx> > Cc: "Gluster Users" <gluster-users@xxxxxxxxxxx>, gluster-devel@xxxxxxxxxxx > Sent: Thursday, May 8, 2014 6:53:04 PM > Subject: Re: Proposal for improvements for heal commands > > > 2) According to the feedback we got, Commands: "gluster volume heal > > <volname> > > info healed/heal-failed" are not helpful in debugging anything. So I am > > thinking of deprecating these two commands. > > Reasons: > > - The commands only give the last 1024 entries that succeeded/failed, so > > most of the times users need to inspect logs. > > Seems reasonable, though if it's just an issue of not keeping enough > information to be useful we could fix that by simply retaining more. Heal info + logs are enough to debug all sorts of problems and we can stop maintaining these commands as no additional value is added. Pranith. > > > 3) "gluster volume heal <volname> info split-brain" will be re-implemented > > to > > print all the files that are in split-brain instead of the limited 1024 > > entries. > > - One constant complaint is that even after the file is fixed from > > split-brain, it may still show up in the previously cached output. In > > this implementation the goal is to remove all the caching and compute > > the > > results afresh. > > This seems reasonable too. I can't help but wonder if it might be worth > tracking split-brain files using a Merkle tree approach like we did with > xtime, so we could track any number of such files efficiently. > We can do this by keeping separate indices for split-brain files as well. Which I want to do in the next iteration. For now gfapi based crawl suffices. Pranith. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
