[Gluster-users] GlusterFS 3.7.2: gluster volume heal <vol> info heal-failed

Ravishankar N ravishankar at redhat.com
Thu Jul 9 01:31:09 UTC 2015



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 at gluster.org
>>> http://www.gluster.org/mailman/listinfo/gluster-users
>>
>



More information about the Gluster-users mailing list