[Gluster-devel] AFR filesystem inconsistency?
mogulguy at yahoo.com
Sun Feb 17 05:51:40 UTC 2008
I am particularly interested in the AFR translator and
am curious about how it is supposed to work and what
are the plans for its future. I am running the debian
packages 1.3.7-0, mentioned on the wiki and have found
the following behavior:
I setup AFR to replicate to two volumes, A & B, each
on separate machines. Both these volumes are
"exported" as a server. I mount the AFR result from a
client to say /mnt and I copy five files to /mnt,
(1,2,3,4,5). I then shutdown one of the servers (A)
and delete file 1 and then restart that server. After
it is restarted if I look at the contents of subvolume
A and it still contains files 1,2,3,4,5, whereas
subvolume B correctly only contains 2,3,4,5. Is this
normal behavior? If I perform an ls on the client
/mnt I correctly get just 2,3,4,5 and then if I check
the subvolumes again, they are in sync 2,3,4,5. So
far, so good, the client always sees the "correct"
view of the filesystem.
But, trouble starts if I perform a similar scenario
slightly differently. Assuming I know have files
2,3,4,5 on both subvolumes and the client /mnt. I
shutdown A again and then delete file 2 from /mnt. I
bring A back up and wait a while but do not access
/mnt. I then shutdown B! Now if I do an ls on /mnt
it still shows me file 2 since it was never deleted
from A and A does not seem aware that B had it delete
on it. This is "incorrect" behavior since someone
deleted file 2 from /mnt and without doing anything to
/mnt, it reappears! Is this by design, a bug, or
simply a not addressed yet issue?
Are there plans to enhance the AFR translator so that
this kind of inconsistency is avoided? Or if this is
desired behavior for some, are there any plans to
build another translator that can be placed above the
AFR that would ensure consistency even when nodes go
Never miss a thing. Make Yahoo your home page.
More information about the Gluster-devel