[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