Re: interpreting heal info and reported entries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



We see the same thing, after a reboot or downtime of one server there are almost always unresolved heal entries. Which renders the whole concept of 3x or 2+1 replication kind of moot.

We could often resolve it by just running "touch" on the files through a FUSE mount, after finding out which files corresponded to the mentioned GFIDs.

We think it must be either a bug or a undocumented behaviour in GlusterFS.

Stefan

----- Original Message -----
> Date: Wed, 29 Jan 2020 16:26:35 +0000
> To: "'gluster-users@xxxxxxxxxxx'" <gluster-users@xxxxxxxxxxx>
> Subject:  interpreting heal info and reported entries
> Message-ID:
>	<650846d7a1c4461ba690479ac1c144f7@xxxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> I have glusterfs (v6.6) deployed with 3-way replication used by ovirt (v4.3).
> I recently updated 1 of the nodes (now at gluster v6.7) and rebooted. When it
> came back online, glusterfs reported there were entries to be healed under the
> 2 nodes that had stayed online.
> After 2+ days, the 2 nodes still show entries that need healing, so I'm trying
> to determine what the issue is.
> The files shown in the heal info output are small so healing should not take
> long. Also, 'Gluster v heal <vol>' and 'gluster v heal <vol> full' both return
> successful, but the entries persist.
> 
> 
> So first off, I'm a little confused by what gluster volume heal <vol> info is
> reporting.
> The following is what I see from heal info:
> 
> # gluster v heal engine info
> Brick repo0:/gluster_bricks/engine/engine
> /372501f5-062c-4790-afdb-dd7e761828ac/images/968daf61-6858-454a-9ed4-3d3db2ae1805/4317dd0d-fd35-4176-9353-7ff69e3a8dc3.meta
> /372501f5-062c-4790-afdb-dd7e761828ac/images/4e3e8ca5-0edf-42ae-ac7b-e9a51ad85922/ceb42742-eaaa-4867-aa54-da525629aae4.meta
> Status: Connected
> Number of entries: 2
> 
> Brick repo1:/gluster_bricks/engine/engine
> /372501f5-062c-4790-afdb-dd7e761828ac/images/968daf61-6858-454a-9ed4-3d3db2ae1805/4317dd0d-fd35-4176-9353-7ff69e3a8dc3.meta
> /372501f5-062c-4790-afdb-dd7e761828ac/images/4e3e8ca5-0edf-42ae-ac7b-e9a51ad85922/ceb42742-eaaa-4867-aa54-da525629aae4.meta
> Status: Connected
> Number of entries: 2
> 
> Brick repo2:/gluster_bricks/engine/engine
> Status: Connected
> Number of entries: 0
> 
> 
> Repo0 and repo1 were not rebooted, but repo2 was.
> Since repo2 went offline I would expect when it came back online it would have
> entries that need healing, but based on the heal info output that's not what it
> looks like, so I'm thinking maybe heal info isn't reporting what I think it is
> reporting.
> 
> *When gluster volume heal <vol> info reports entries as above, what is it
> saying?
> 
________

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/441850968

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/441850968

Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users



[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux