[Gluster-devel] DHT proposal for Gluster 4.0

Shyam srangana at redhat.com
Mon Jan 12 18:45:22 UTC 2015


Hi,

There have been some discussions about DHT and what it could be in 
Gluster 4.0 or the next major revision of DHT/Gluster.

Here, [1] 
https://docs.google.com/document/d/15_TOW9jwzW4griAmk-rqg2cWF-LHiR_TJ8Jn0vOvYpU/edit?usp=sharing 
is a google document on the various thoughts and in particular extending 
DHT2 proposal in terms of what it could mean to Gluster.

This document [1] is really is a culmination of various ideas presented 
before and some expansion of them, so there are quite a few who have 
been directly or indirectly involved. The attempt here is to get more 
eyes and brains into the discussion, to take the design and 
implementation forward.

Requesting the devel list to go through the document and 
comment/suggest/analyze, to take the thoughts forward (either on the 
google doc itself or here on the devel list).

<sneak peek>
## Proposal

We start by "flattening" the on-disk (on-brick) representation of the 
user's directory hierarchy.  Every object in a volume, including the 
root, is stored directly in the brick root, named by GFID.  The only 
place real names appear is at the second level, within each directory, 
and is used only to map a parent GFID plus basename to a child GFID.

Non-directories exist only on one subvolume - the one selected by 
consistent hashing on its GFID  at the time it was created or rebalanced...

</sneak peek>

Thanks,
Shyam


More information about the Gluster-devel mailing list