On 03/01/2015 10:58 AM, Emmanuel Dreyfus wrote:
Hi
I am trying to understand why read-subvol-entry.t almost always fail on
NetBSD. Here is how it goes:
- create a 2-brick replicated volume
- mkdir -p $M0/abc/def
- set:
self-heal-daemon off
stat-prefetch off
cluster.background-self-heal-count 0
cluster.data-self-heal off
cluster.metadata-self-heal off
cluster.entry-self-heal off
- kill brick0
- touch $M0/abc/def/ghi
- restart brick0
- check for ghi in ls $M0/abc/def/
How is it supposed to heal? If I understand correctly, the touch
$M0/abc/def/ghi causes AFR xtattr to be created on $M0/abc/def/ for the
operatione not done on brick0. Later the READDIR operation from ls
$M0/abc/def/ should cause AFR to notice the AFR xattr and perform the
heal.
I think I added the testcase for afr-v1 code. Since
cluster.{data/metadata/entry}self-heal is set to off,
lookup/readdir will *not* trigger heal in afr-v1. i.e. ghi would not be
created in brick0 despite the "EXPECT_WITHIN $PROCESS_UP_TIMEOUT "ghi"
echo `ls $M0/abc/def/`"
Thus what the test was checking is that in spite of not healing, the
client still got the correct data by reading from brick1.
In afr-v2, lookup does not trigger data/metadata/entry anyway. Only
'name' self-heals are done. i.e. ghi is created but its data and
metadata are not healed. These are taken care only by the self-heal-daemon.
In other words, client side healing in v2 is restricted to name
self-heals only.
HTH,
Ravi
Is it the way it should behave? If it is, then where is the relevant
code in xlator/cluster/afr/src ?
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
