Changes between Initial Version and Version 36 of Ticket #2107
- Timestamp:
- 2014-01-21T12:29:05Z (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #2107
- Property Keywords space-efficiency added
- Property Cc amontero@… warner added
-
Ticket #2107 – Description
initial v36 9 9 This requirement is more for usability and consistency than any clear availability criteria. Space utilization in distributed filesystems is an important issue. Many commodity computing services charge based on the amount of space used. So, in a practical distributed system, it is important for the user to be able to reason about space usage in a precise way. Explicit erasure-coding or replication parameters provided to the user allow the user to do this. We argue that it is not appropriate for an algorithm to second-guess the user’s choices, and say instead that the user will increase n, k, or r if they want more data stored on the filesystem. 10 10 11 That's a pretty good argument! Especially the part about "You're paying for that space, and if you upload 2 or 3 shares to one server, you're paying 2 or 3 times as much, but not getting much fault-tolerance in return for it.". 11 That's a pretty good argument! Especially the part about "You're paying for that space, and if you upload 2 or 3 shares to one server, you're paying 2 or 3 times as much, but not getting much fault-tolerance in return for it.". See also [https://tahoe-lafs.org/pipermail/tahoe-dev/2013-September/008694.html this post] on tahoe-dev. 12 12 13 13 I would add that if a user is diagnosing the state of their grid, or reasoning about possible future behavior of their grid, it will be more intuitive and easier for them (at least for many people) to think about if they can assume that shares will never be intentionally doubled-up.
