Displaying 3 results from an estimated 3 matches for "0x000000000000000000000001since".
2023 Feb 07
1
File\Directory not healing
Hi All.
Hoping you can help me with a healing problem. I have one file which didn't
self heal.
it looks to be a problem with a directory in the path as one node says it's
dirty. I have a replica volume with arbiter
This is what the 3 nodes say. One brick on each
Node1
getfattr -d -m . -e hex /path/to/dir | grep afr
getfattr: Removing leading '/' from absolute path names
2023 Feb 14
1
File\Directory not healing
I've touched the directory one level above the directory with the I\O issue
as the one above that is the one showing as dirty.
It hasn't healed. Should the self heal daemon automatically kick in here?
Is there anything else I can do?
Thanks
David
On Tue, 14 Feb 2023 at 07:03, Strahil Nikolov <hunter86_bg at yahoo.com> wrote:
> You can always mount it locally on any of the
2023 Feb 14
1
File\Directory not healing
...fattr: Removing leading '/' from absolute path namestrusted.afr.volume-client-2=0x000000000000000000000001trusted.afr.dirty=0x000000000000000000000000Node3(Arbiter)getfattr -d -m . -e hex /path/to/dir | grep afrgetfattr: Removing leading '/' from absolute path namestrusted.afr.dirty=0x000000000000000000000001Since Node3(the arbiter) sees it as dirty and it looks like Node 1 and Node 2 have good copies, I was thinking of running the following on Node1 which I believe would tell Node 2 and Node 3 to sync from Node 1
I'd then kick off a heal on the volume
setfattr -n trusted.afr.volume-client-1 -v 0x0000000...