[tahoe-lafs-trac-stream] [tahoe-lafs] #390: 'readonly_storage' and 'reserved_space' not honored for mutable-slot write requests

[tahoe-lafs]

#390: 'readonly_storage' and 'reserved_space' not honored for mutable-slot write
requests
-------------------------+-------------------------------------------------
     Reporter:  warner   |      Owner:
         Type:  defect   |     Status:  new
     Priority:  major    |  Milestone:  eventually
    Component:  code-    |    Version:  1.0.0
  storage                |   Keywords:  reliability mutable backend
   Resolution:           |  availability anti-censorship
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by gdt):

 Duplicated from http://tahoe-lafs.org/trac/tahoe-
 lafs/ticket/1568#comment:6

 I don't really follow this. It seems reasonable for a server operator to
 decide to not accept new shares, and for this to be separate than whether
 the server process is able to write the filesystem where the shares are
 kept. For example, it might be reasonable to allow lease renewal, or for
 other metadata to be updated. It might be that not accepting shares should
 be similar to zero space available, so increasing the size of a mutable
 share also might not be allowed. And, if the purpose really is
 decommissioning, then presumably the mechanism used for repair should
 somehow signal that the share is present but should be migrated, so that a
 deep-check --repair can put those shares on some other server.

 There's a difference between people that don't understand enough to
 sysadmin a server, and the server having uniform configuation for server-
 level behavior. When tahoe is ported to
 [http://en.wikipedia.org/wiki/Incompatible_Timesharing_System ITS], it
 should still be possible to tell it to stop taking shares.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/390#comment:25>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage