id summary reporter owner description type status priority milestone component version resolution keywords cc launchpad_bug 671 bring back sizelimit (i.e. max consumed, not min free) zooko markberger "We used to have a {{{sizelimit}}} option which would do a recursive examination of the storage directory at startup and calculate approximately how much disk space was used, and refuse to accept new shares if the disk space would exceed the limit. #34 shows when it was implemented. It was later removed because it took a long time -- about 30 minutes -- on allmydata.com storage servers, and the servers remained unavailable to clients during this period, and because it was replaced by the {{{reserved_space}}} configuration, which was very fast and which satisfied the requirements of the allmydata.com storage servers. This ticket is to reintroduce {{{sizelimit}}} because [//pipermail/tahoe-dev/2009-March/001493.html some users want it]. This might mean that the storage server doesn't start serving clients until it finishes the disk space inspection at startup. Note that {{{sizelimit}}} would impose a maximum limit on the amount of space consumed by the node's {{{storage/shares/}}} directory, whereas {{{reserved_space}}} imposes a minimum limit on the amount of remaining available disk space. In general, {{{reserved_space}}} can be implemented by asking the OS for filesystem stats, whereas {{{sizelimit}}} must be implemented by tracking the node's own usage and accumulating the sizes over time. To close this ticket, you do *not* need to implement some sort of interleaving of inspecting disk space and serving clients. To close this ticket, you MUST NOT implement any sort of automatic deletion of shares to get back under the sizelimit if you find yourself over it (for example, if the user has changed the sizelimit to be lower after you've already filled it to the max), but you SHOULD implement some sort of warning message to the log if you detect this condition. " defect new major soon code-nodeadmin 1.3.0 usability statistics sftp docs frederik.braun+tahoe@…