Re: AFR filesystem inconsistency?

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

 



Hi Martin,

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)

Regards
Krishna

On Feb 17, 2008 11:21 AM, Martin Fick <mogulguy@xxxxxxxxx> 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
> down?
>
> Thanks,
>
> -Martin
>
>
>
>
>       ____________________________________________________________________________________
> Never miss a thing.  Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel@xxxxxxxxxx
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>




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

  Powered by Linux