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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
