tahoe-lafs/trac-2024-07-25

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

New issue

Open

opened 2008-07-01 23:26:47 +00:00 by warner · 0 comments

warner commented

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

Owner

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

tahoe-lafs added the

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

tahoe-lafs added this to the undecided milestone 2008-07-01 23:26:47 +00:00

Sign in to join this conversation.

No labels

LeastAuthority.com automation

cannot reproduce

code-frontend-cli

code-frontend-ftp-sftp

code-frontend-magic-folder

code-frontend-web

code-peerselection

dev-infrastructure

somebody else's problem

was already fixed

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#480

No description provided.