[Gluster-devel] AFR self-heal issues.

Krishna Srinivas krishna at zresearch.com
Tue Feb 19 03:44:10 UTC 2008


Hi Sam,
A fix is in the works regarding the order of the subvols you mentioned.
Krishna

On Feb 19, 2008 8:21 AM, Sam Douglas <sam.douglas32 at gmail.com> wrote:
> Hi,
>
> == Background ==
>
> We are setting up GlusterFS on a compute cluster. Each node has two
> disk partitions /media/gluster1 and /media/gluster2 which are used for
> the cluster storage.
>
> We are currently using  builds from TLA (671 as of now)
>
> I have a script to generate GlusterFS client configurations that
> create AFR instances over pairs of nodes in the cluster, a snippet
> from our current configuration:
>
> # Client definitions
> volume client-cn2-1
>         type protocol/client
>         option transport-type tcp/client
>         option remote-host cn2
>         option remote-subvolume brick1
> end-volume
>
> volume client-cn2-2
>         type protocol/client
>         option transport-type tcp/client
>         option remote-host cn2
>         option remote-subvolume brick2
> end-volume
>
> volume client-cn3-1
>         type protocol/client
>         option transport-type tcp/client
>         option remote-host cn3
>         option remote-subvolume brick1
> end-volume
>
> volume client-cn3-2
>         type protocol/client
>         option transport-type tcp/client
>         option remote-host cn3
>         option remote-subvolume brick2
> end-volume
>
> ### snip - you get the idea ###
>
> # Generated AFR volumes
> volume afr-cn2-cn3
>         type cluster/afr
>         subvolumes client-cn2-1 client-cn3-2
> end-volume
>
> volume afr-cn3-cn4
>         type cluster/afr
>         subvolumes client-cn3-1 client-cn4-2
> end-volume
>
>
> ### and so on ###
>
> volume unify
>         type cluster/unify
>         option scheduler rr
>         option namespace namespace
>         subvolumes  afr-cn2-cn3 afr-cn3-cn4 afr-cn4-cn5 ...
> end-volume
>
>
> == Self healing program ==
>
> I wrote a quick C program (medic) that uses the nftw function and
> opens all files in a directory tree, and readlinks all symlinks. This
> seems effective at forcing AFR to heal.
>
>
> == Playing with AFR ==
>
> We have a test cluster of 6 nodes set up.
>
> In this setup, cluster node 2 is involved in 'afr-cn2-cn3' and
> 'afr-cn7-cn2'.
>
> I copy a large directory tree onto the cluster filesystem (such as
> /usr), then 'cripple' node cn2 by deleting the data from its backends
> and restarting glusterfsd on that system; to emulate the system going
> offline/losing data.
>
> (at this point, all the data is still available on the filesystem)
>
> Running medic over the filesystem mount will now cause the data to be
> copied back onto cn2's appropriate volumes and all is happy.
>
> Opening all files on the filesystem seems a stupid waste of time if
> you know which volumes have gone down (and when you have over 20TB in
> hundreds of thousands of files, that is a considerable waste of time),
> so I looked into mounting the parts of the client translator tree into
> separate mount points and running medic over those.
>
>  # mkdir /tmp/glfs
>  # generate_client_conf > /tmp/glusterfs.vol
>  # glusterfs -f /tmp/glusterfs.vol -n afr-cn2-cn3 /tmp/glfs
>  # ls /tmp/glfs
>     home/
>     [Should be: home/ usr/]
>
> A `cd /tmp/glfs/usr/` will succeed and usr/ will be self-healed, but
> the contents will not. Likewise a `cat /tmp/glfs/usr/include/stdio.h`
> will output the contents of the file and cause it to be self-healed.
>
> Changing the order of the subvolumes to the 'afr-cn2-cn3' volume so
> that the up to date client is the first volume causes the directory to
> be correctly listed.
>
> This seems to me like a minor-ish bug in cluster/afr's readdir
> functionality.
>
> -- Sam Douglas
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>





More information about the Gluster-devel mailing list