tahoe-lafs/trac-2024-07-25

mutable-retrieve should accept good shares from servers with bad shares #1653

New issue

Open

opened 2012-01-09 03:16:53 +00:00 by warner · 0 comments

warner commented

2012-01-09 03:16:53 +00:00

Owner

retrieve.py is currently rather punitive when it detects corrupt shares: it stops using any shares from the same server. This doesn't have much effect when there are plenty of servers and the shares are spread thinly, but in small personal grids, a single corrupt share could disqualify enough shares that the retrieve fails.

I think this behavior was copied from the old immutable downloader. The new immutable downloader doesn't do this: it treats each share independently.

To fix this, _mark_bad_share and _remove_reader should remove just the one share from self.remaining_sharemap, instead of all shares with the same server. We also need to look for other calls to _remove_reader(), since I think there may be some which are supposed to stop all shares from the same server.

retrieve.py is currently rather punitive when it detects corrupt shares: it stops using *any* shares from the same server. This doesn't have much effect when there are plenty of servers and the shares are spread thinly, but in small personal grids, a single corrupt share could disqualify enough shares that the retrieve fails. I think this behavior was copied from the old immutable downloader. The new immutable downloader doesn't do this: it treats each share independently. To fix this, `_mark_bad_share` and `_remove_reader` should remove just the one share from `self.remaining_sharemap`, instead of all shares with the same server. We also need to look for other calls to `_remove_reader()`, since I think there may be some which *are* supposed to stop all shares from the same server.

tahoe-lafs added the

labels 2012-01-09 03:16:53 +00:00

tahoe-lafs added this to the eventually milestone 2012-01-09 03:16:53 +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#1653

No description provided.