[tahoe-lafs-trac-stream] [tahoe-lafs] #1568: S3 backend: [storage]readonly is documented but ignored

tahoe-lafs trac at tahoe-lafs.org
Mon Oct 24 11:29:23 PDT 2011


#1568: S3 backend: [storage]readonly is documented but ignored
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  zooko
  davidsarah             |     Status:  assigned
         Type:  defect   |  Milestone:  1.10.0
     Priority:  major    |    Version:  1.9.0b1
    Component:  code-    |   Keywords:  s3-backend readonly storage lae
  storage                |  review-needed
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by davidsarah):

 Replying to [comment:6 gdt]:
 > For example, it might be reasonable to allow lease renewal, or for other
 metadata to be updated.

 However, that doesn't affect the S3 backend, which doesn't store lease
 data in shares. We plan to store it in a leasedb that is local to the
 server.

 > 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.

 Making the storage read-only has the effect of preventing any changes to
 shares.

 If we want a "don't use any more space" option, that's different to "read-
 only". I think "read-only", if supported, should mean precisely that
 (including preventing deletion of shares or reductions in size of mutable
 shares).

 Note that removing {{{[storage]readonly}}} for the S3 backend now doesn't
 mean that we won't support it in future. Currently the option doesn't work
 at all for the S3 backend, and we would have to spend effort implementing
 it that would delay (even if not by much) finishing the backend.

 > 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.

 True, but I think that should be a separate option.

 > 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.

 Thanks for volunteering to do the ITS port! ;-)

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


More information about the tahoe-lafs-trac-stream mailing list