[tahoe-dev] [tahoe-lafs] #893: UCWE when mapupdate gives up too early, then server errors require replacement servers
tahoe-lafs
trac at allmydata.org
Wed Jan 13 15:53:39 PST 2010
#893: UCWE when mapupdate gives up too early, then server errors require
replacement servers
----------------------------------------+-----------------------------------
Reporter: warner | Owner:
Type: defect | Status: new
Priority: critical | Milestone: 1.6.0
Component: code-mutable | Version: 1.5.0
Keywords: availability upload repair | Launchpad_bug:
----------------------------------------+-----------------------------------
Comment(by zooko):
So there are three proposals for code changes in this ticket.
1. The finish-criteria code for MODE_WRITE
({{{ServermapUpdater._check_for_done}}}) should not let the process finish
unless we've received answers from at least {{{self.num_peers_to_query}}},
just like MODE_READ (or if we've run out of servers to query).
2. When sending a share to a server that you do ''not'' have any
information about in your servermap, then go ahead and include a test
vector saying "This share is intended to overwrite any share with version
less than V.". Brian: does that sound like it could cause some weird
problem? It sounds pretty safe to me.
3. Invent a new exception named {{{MultipleVersionsExisted}}} and raise
that instead of {{{UncoordinatedWriteError}}} if you didn't see actual
evidence of a server changing its store between your mapupdate and your
write. I earlier proposed that {{{UncoordinatedWriteError}}} could be a
subtype of {{{MultipleVersionsExisted}}}, but I'm not sure whether it
should be a subtype or just a separate type. Either way is fine with me.
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/893#comment:8>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
More information about the tahoe-dev
mailing list