[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