[Gluster-users] Strange behaviour in AFR - directory read only from first brick?

[Anand Avati]

this case is considered equal to 'altering the backend without the mount
point'. currently it is an unsupported 'action'.

avati

On 03/07/2008, Arnulf Heimsbakk <arnulf.heimsbakk at gmail.com> wrote:
>
> Hi,
>
> I find GlusterFS as a refreshing alternative to traditional cluster
> file systems. I have currently experimented with unify and AFR. When
> experimenting with AFR with two bricks I found a strange behaviour. It
> seems that the directory is only read from the first brick.
>
> I created two bricks and run client side AFR. In the client config the
> bricks is represented as follows:
>
> subvolumes brick1 brick2
>
> Then I simulated a crash with loss of files.
>
> 1. AFR is up
> 2. touch file f1
> 3. brick1 crashes
> 4. ls on mount point, f1 exists and everything is normal (ls read from
> brick2)
> 5. file system repair removes f1 from brick1
> 6. gclusterfsd start on brick1
> 7. ls on mount point does not show f1 anymore (ls read only from brick1?)
> 8. cat f1 on mount point replicates file and it becomes visible
>
> I have replicated this error a numerous times. Every time i have
> removed user_xattr from the exported directories.
>
> GlusterFS version 1.3.8
> XFS backend filesystem
> Debian Etch i686
>
> Is there a fix for this behaviour or is there a configuration solution
> which eliminates this problem?
> Or is this problem considered to be a split brain case?
> Does this affect AFRd namespaces (i did not test that)?
>
> Arnulf Heimsbakk
> Sysadmin @ Norwegian Meteorological Institute
>
> --
> "When all else fails, read the instructions." ~ L. Iasellio
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
>



-- 
If I traveled to the end of the rainbow
As Dame Fortune did intend,
Murphy would be there to tell me
The pot's at the other end.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20080703/4421ffb2/attachment.html>