mutable storage-server API needs a way to refuse shares #480

New Issue

warner · 2008-07-01T23:26:47Z

warner commented

2008-07-01 23:26:47 +00:00

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

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