[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