Opened at 2009-03-29T04:07:10Z
Last modified at 2021-03-30T18:40:19Z
#671 new defect
sizelimit — at Initial Version
| Reported by: | zooko | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | soon |
| Component: | code-nodeadmin | Version: | 1.3.0 |
| Keywords: | usability statistics sftp docs | Cc: | frederik.braun+tahoe@… |
| Launchpad Bug: |
Description
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 some users want it. This will mean that the storage server doesn't start serving clients until it finishes the disk space inspection at startup.
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.
