]> git.rkrishnan.org Git - tahoe-lafs/tahoe-lafs.git/commit
immutable: storage servers accept any size shares now
authorZooko O'Whielacronx <zooko@zooko.com>
Wed, 31 Dec 2008 22:42:26 +0000 (15:42 -0700)
committerZooko O'Whielacronx <zooko@zooko.com>
Wed, 31 Dec 2008 22:42:26 +0000 (15:42 -0700)
commit6c4019ec33e7a253695bf7314dabfb39343b0ddc
treed3e3bcdf3b09aff85e4b12fbe2950f619628bdb1
parent0687f692b0e6b0e64639214a3d32f0666c959718
immutable: storage servers accept any size shares now
Nathan Wilcox observed that the storage server can rely on the size of the share file combined with the count of leases to unambiguously identify the location of the leases.  This means that it can hold any size share data, even though the field nominally used to hold the size of the share data is only 32 bits wide.

With this patch, the storage server still writes the "size of the share data" field (just in case the server gets downgraded to an earlier version which requires that field, or the share file gets moved to another server which is of an earlier vintage), but it doesn't use it.  Also, with this patch, the server no longer rejects requests to write shares which are >= 2^32 bytes in size, and it no longer rejects attempts to read such shares.

This fixes http://allmydata.org/trac/tahoe/ticket/346 (increase share-size field to 8 bytes, remove 12GiB filesize limit), although there remains open a question of how clients know that a given server can handle large shares (by using the new versioning scheme, probably).

Note that share size is also limited by another factor -- how big of a file we can store on the local filesystem on the server.  Currently allmydata.com typically uses ext3 and I think we typically have block size = 4 KiB, which means that the largest file is about 2 TiB.  Also, the hard drives themselves are only 1 TB, so the largest share is definitely slightly less than 1 TB, which means (when K == 3), the largest file is less than 3 TB.

This patch also refactors the creation of new sharefiles so that only a single fopen() is used.

This patch also helps with the unit-testing of repairer, since formerly it was unclear what repairer should expect to find if the "share data size" field was corrupted (some corruptions would have no effect, others would cause failure to download).  Now it is clear that repairer is not required to notice if this field is corrupted since it has no effect on download.  :-)
src/allmydata/storage.py
src/allmydata/test/test_storage.py