Opened at 2008-07-01T23:26:47Z
Last modified at 2010-02-11T03:53:44Z
#480 new defect
mutable storage-server API needs a way to refuse shares
Reported by: | warner | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | undecided |
Component: | code-mutable | Version: | 1.1.0 |
Keywords: | mutable reliability error | Cc: | |
Launchpad Bug: |
Description
Related to #390, we need to give storage servers the ability to refuse a writev() request. It will probably be sufficient to let it raise some well-known exception (WriteRefusedError?), but it would be nice to not have both ends log it as if it were unexpected. Tahoe-1.0 clients will also fail to handle many errors during writev calls: the DeferredList-without-fireOnOneError bug.
A useful intermediate point on #390 (dealing with servers that are in readonly mode) would be to refuse writev() that creates new shares, but allow them to modify existing shares. That would reduce the data influx rate while not triggering as many problems (if old shares are not allowed to be rewritten, the tahoe-1.1 client will copy the share elsewhere, but the old share will stick around, causing rollbacks).
Change History (1)
comment:1 Changed at 2010-02-11T03:53:44Z by davidsarah
- Keywords mutable reliability error added