[tahoe-dev] [tahoe-lafs] #1157: new downloader should reuse shares with only partial corruption
tahoe-lafs
trac at tahoe-lafs.org
Thu Aug 5 18:31:33 UTC 2010
#1157: new downloader should reuse shares with only partial corruption
---------------------------+------------------------------------------------
Reporter: warner | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: undecided
Component: code-encoding | Version: 1.8β
Keywords: | Launchpad Bug:
---------------------------+------------------------------------------------
during the work on #1154, I was reminded that I made an
expedient/conservative choice during my recent new-downloader work: once
we see any corruption in a share, we completely give up on it. It would be
nice if we could get value out of partially-corrupted shares.
Specifically, when the block data for e.g. segment0 is corrupted, we
should still be able to get block data for segment1.
This change will show up in
source:src/allmydata/immutable/downloader/fetcher.py#L222 , in
{{{SegmentFetcher._block_request_activity}}}, in the handling of
{{{state=CORRUPT}}} (that state will probably go away, or become per-
segment).
I plan to defer this work until we get a "sort shares by quality" scheme
in place, where the general idea is to put the "best" shares (fastest,
most-data-already-downloaded) at the top of the list, occasionally try out
new shares for serendipity, and put slow/tardy shares at the bottom. In
this system, corruption would move a share to the bottom of the list, but
would not discard it completely.
There is a test (test_download.py,
{{{DownloadTest.test_simultaneous_onefails}}}) which will need to be
updated when this is fixed, since it asserts that two simultaneous
segment reads (one for a segment that we've intentionally corrupted, the
other for an uncorrupted segment) results in two failures, whereas once
we've fixed this it will result in one failure and one success.
--
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1157>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage
More information about the tahoe-dev
mailing list