[Gluster-devel] AFR filesystem inconsistency?
krishna at zresearch.com
Sun Feb 17 17:02:28 UTC 2008
Since selfheal is done only on demand this issue is seen.
However you can get around this problem if after bringing
up the downed server you do a "find . > /dev/null" from the
root directory (which would call lookup() on every directory,
lookup() code has the code to fix the issue you are seeing)
On Feb 17, 2008 11:21 AM, Martin Fick <mogulguy at yahoo.com> wrote:
> 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.
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
More information about the Gluster-devel