[tahoe-dev] [tahoe-lafs] #671: sizelimit

[tahoe-lafs]

#671: sizelimit
----------------------------+-----------------------------------------------
 Reporter:  zooko           |           Owner:       
     Type:  defect          |          Status:  new  
 Priority:  major           |       Milestone:  1.3.2
Component:  code-nodeadmin  |         Version:  1.3.0
 Keywords:                  |   Launchpad_bug:       
----------------------------+-----------------------------------------------
 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
 [http://allmydata.org/pipermail/tahoe-dev/2009-March/001493.html 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.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/671>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid