[Gluster-users] Per-directory brick preference?

[Philip Poten]

2011/6/20 Jeff Darcy <jdarcy at redhat.com>

> > server1:bigdisk,server1:smalldisk,server2:bigdisk,server2:smalldisk
>
> Are you sure? [...]
>

Nope, sorry, my bad :) I wrote that from memory.


> There is kind of a way to do this, but it's distinctly non-kosher so I
> have to slap a big planet-sized "caveat emptor" on it.  As is explained
> in an article I wrote a while ago
> (http://cloudfs.org/2011/04/glusterfs-extended-attributes/) the "layout
> map" that controls placement of files within a directory is actually
> stored in an extended attribute on each copy of that directory (one copy
> per brick).  Therefore, by manipulating these extended attributes from
> the command line you could affect placement of files in any number of
> ways including the way you mention.  In that case, you would set the
> xattrs on each server to "claim" hash ranges (see the article) as follows:
>
>        bigdisk/bigdir     - 0x00000000 to 0xfffffffe
>        bigdisk/smalldir   - 0xffffffff to 0xffffffff
>        smalldisk/bigdir   - 0xffffffff to 0xffffffff
>        smalldisk/smalldir - 0x00000000 to 0xfffffffe
> [...]


This is extremely valuable information, thank you for that. It won't fix my
problem (for the reasons you mention below), but it is a very handy way to
"mark" temporary directories and such during maintenance. Very good.


> After doing
> this, "gluster volume rebalance xxx migrate-data start" should cause
> files to be migrated to the "correct" locations, but with two major
> caveats.
>
> (1) A subsequent "gluster volume rebalance xxx fix-layout start" will
> undo your careful xattr-twiddling, so that files will no longer be
> placed the way you intended.
>
> (2) These values are not inherited by subdirectories (that would be a
> very good subject for an enhancement request) so the careful placement
> would only apply to the top-level directories.


Yeah, no, seems like I won't go there. But being able to choose from
different layout strategies per directory in the future ... that would be
sweet.

Again, thanks a bunch for the above information,
Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20110621/38208c76/attachment.html>