[Gluster-devel] Proposal for improvements for heal commands

Pranith Kumar Karampuri pkarampu at redhat.com
Mon May 12 08:19:50 UTC 2014



----- Original Message -----
> From: "Jeff Darcy" <jdarcy at redhat.com>
> To: "Pranith Kumar Karampuri" <pkarampu at redhat.com>
> Cc: "Gluster Users" <gluster-users at gluster.org>, gluster-devel at gluster.org
> Sent: Thursday, May 8, 2014 6:53:04 PM
> Subject: Re: [Gluster-devel] 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.



More information about the Gluster-devel mailing list