]> git.rkrishnan.org Git - tahoe-lafs/tahoe-lafs.git/commit
storage: make two levels of share directories so as not to exceed certain filesystems...
authorZooko O'Whielacronx <zooko@zooko.com>
Thu, 31 Jan 2008 23:26:28 +0000 (16:26 -0700)
committerZooko O'Whielacronx <zooko@zooko.com>
Thu, 31 Jan 2008 23:26:28 +0000 (16:26 -0700)
commit79c439d026379a582037d0449c22f82eba70d554
treec94f130add3bbe35bcdb39e5f985f75171fc5a5e
parentbf25a041f32277863673b180f51e58716caf92e6
storage: make two levels of share directories so as not to exceed certain filesystems's limitations on directory size
The filesystem which gets my vote for most undeservedly popular is ext3, and it has a hard limit of 32,000 entries in a directory.  Many other filesystems (even ones that I like more than I like ext3) have either hard limits or bad performance consequences or weird edge cases when you get too many entries in a single directory.

This patch makes it so that there is a layer of intermediate directories between the "shares" directory and the actual storage-index directory (the one whose name contains the entire storage index (z-base-32 encoded) and which contains one or more share files named by their share number).

The intermediate directories are named by the first 14 bits of the storage index, which means there are at most 16384 of them.  (This also means that the intermediate directory names are not a leading prefix of the storage-index directory names -- to do that would have required us to have intermediate directories limited to either 1024 (2-char), which is too few, or 32768 (3-chars of a full 5 bits each), which would overrun ext3's funny hard limit of 32,000.))

This closes #150, and please see the "convertshares.py" script attached to #150 to convert your old tahoe-0.7.0 storage/shares directory into a new tahoe-0.8.0 storage/shares directory.
src/allmydata/storage.py
src/allmydata/test/test_storage.py
src/allmydata/test/test_system.py