On 07/08/2015 09:29 PM, Andreas Hollaus wrote:
Hi,
I'm actually using an older version (3.6.2), but we plan to upgrade to
3.7.2 so I guess the question didn't refer to a specific version.
# gluster volume heal
Usage: volume heal <VOLNAME> [{full | statistics {heal-count {replica
<hostname:brickname>}} |info {healed | heal-failed | split-brain}}]
# gluster volume heal c_glusterfs info heal-failed
Command not supported. Please use "gluster volume heal c_glusterfs
info" and logs to find the heal information.
As it is part of the usage string, I thought it was something that
would be implemented later on. My bad...
Regarding the bugzilla case, was this implemented according to the
plans, i.e. does gluster volume heal <vol> info examine all the files
by itself or does it rely on anything else? Can we expect the same
behaviour when we ask for a report of split-brain files? The reason I
ask is that I think it executes rather quickly. I need to know that we
can trust that the output is valid when the command is issued and does
not reflect the situation a (undefined) while ago.
Hi Andreas,
Yes, in the latest release, `heal info` and `heal info split-brain`
examine and print the status at that point in time when the command was
executed. When you run the command, it invokes a separate binary
(`glfsheal`) which does all the processing. The second command is a
subset of the first one and lists only the split-brain files while the
former lists all files (including the split brained ones) that need heal.
Regards,
Ravi
In this implementation the goal is to remove all the caching and
compute the results afresh.
Regards
Andreas
On 07/08/2015 05:32 PM, Ravishankar N wrote:
On 07/08/2015 04:31 PM, Andreas Hollaus wrote:
Hi,
I'm curious about this 'gluster volume heal <vol> info heal-failed'
command:
What would be a possible reason for healing to fail and get listed
by this command? I
know about split-brain, but as that is another option for the
command I suspect that
this would list files that could not be healed but still not
split-brain files, right?
info healed and info heal-failed were deprecated long ago [1].
Running these commands should indicate that the command is not
supported. If you're observing otherwise on 3.7.2, something is
indeed fishy.
Regards,
Ravi
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1098027#c0
On what does it base it's report? Does it investigate the filesystem
by itself, or
does it depend on results from any another command or internal
action? It executes so
quickly that I suspect that it make use of some internal data
structure. If so, is
this data structure always kept up-to-date or is it updated at a
fixed interval?
Regards
Andreas
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users
