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://gluster.org/pipermail/gluster-users/attachments/20110621/38208c76/attachment.htm>
