report maximum-immutable-share-size correctly in light of filesystem limits #1849

Open
opened 2012-11-09 04:51:08 +00:00 by zooko · 0 comments
zooko commented 2012-11-09 04:51:08 +00:00
Owner

Currently storage servers report their maximum-immutable-share-size equal to their available disk space. This is not right for filesystems which limit filesize to a smaller size than the filesystem size, such as ext4, which limits files to 16 TB and filesystems to 1 EB.

http://en.wikipedia.org/wiki/Comparison_of_filesystems#Limits

To fix this ticket, make the disk backend report the filesize limit separately from the available space (probably by hardcoding the facts from wikipedia's table into it) and make the storage server cap its reported maximum-immutable-share-size according to that limit.

The cloud storage backend has no hard limit on share size.

Currently storage servers report their `maximum-immutable-share-size` equal to their available disk space. This is not right for filesystems which limit filesize to a smaller size than the filesystem size, such as ext4, which limits files to 16 TB and filesystems to 1 EB. <http://en.wikipedia.org/wiki/Comparison_of_filesystems#Limits> To fix this ticket, make the disk backend report the filesize limit separately from the available space (probably by hardcoding the facts from wikipedia's table into it) and make the storage server cap its reported `maximum-immutable-share-size` according to that limit. The cloud storage backend has no hard limit on share size.
tahoe-lafs added the
code-storage
normal
defect
1.9.2
labels 2012-11-09 04:51:08 +00:00
tahoe-lafs added this to the undecided milestone 2012-11-09 04:51:08 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#1849
No description provided.