[Gluster-users] understanding dht value

[Jeff Darcy]

> Thanks for pointing to the article. I have been following the article all the
> way. What intrigues me is the dht values associated with sub directories.

> [root at glusterhackervm3 glus]# getfattr -n trusted.glusterfs.dht -e hex
> /brick2/vol
> getfattr: Removing leading '/' from absolute path names
> # file: brick2/vol
> trusted.glusterfs.dht=0x00000001000000007ffffde2ffffffff

> [root at glusterhackervm3 glus]# getfattr -n trusted.glusterfs.dht -e hex
> /brick2/vol/d/
> getfattr: Removing leading '/' from absolute path names
> # file: brick2/vol/d/
> trusted.glusterfs.dht=0x0000000100000000000000007ffffffe

> Does it mean that only files whose DHT value ranges from 0x00 to 0x 7ffffffe
> can be saved inside the ‘d’ directory. But then it provides a very narrow
> range of 0x7ffffde2 to 0x 7ffffffe to be created in that directory.

To know the distribution for a directory as seen by the user, you need to look at the xattrs for the matching directory on every brick. What the above shows us is that, *for this brick*: 

   in brick2/vol, this brick will store files with hashes from 7ffffde2 to ffffffff

   in the subdirectory /brick2/vol/d, this brick will store files from 00000000 to 7ffffffe

Note that this is *completely independent* for each directory, and only affects placement of non-directories.  There's no set-intersection going on between the ranges for a directory and its parent(s).  The subdirectory looks like what I'd expect to see for a volume with two (possibly replicated) DHT subvolumes.  The root looks a lot weirder - almost, but not quite, the top half of the hash distribution.  I think this could happen if here had been multiple brick additions/removals and rebalances, but I'm not sure what that combination would have to be.  If .../d had been created later, it would be unaffected by all of these prior actions and would still get an exactly-half share of the hash range.