]> git.rkrishnan.org Git - tahoe-lafs/tahoe-lafs.git/commit
Wed Dec 28 05:33:58 GMT 2011 Brian Warner <warner@lothar.com>
authorDaira Hopwood <daira@jacaranda.org>
Thu, 5 Sep 2013 17:00:31 +0000 (18:00 +0100)
committerDaira Hopwood <daira@jacaranda.org>
Thu, 5 Sep 2013 17:00:31 +0000 (18:00 +0100)
commit6150fcc6a64c0ef9cf4900fcddb2b48831d6e9b8
tree85506962dfb13de162642e530371aabe49ec8829
parent9e22661f159729b68ab86be205b3f45ea06b71aa
Wed Dec 28 05:33:58 GMT 2011  Brian Warner <warner@lothar.com>
  * mutable publish: track multiple servers-per-share. Fixes some of #1628.

  The remaining work is to write additional tests.

  src/allmydata/test/no_network.py:

   This supports tests in which servers leave the grid only to return with
   their shares intact at a later time.

  src/allmydata/test/test_mutable.py:

   The UCWEs in the incident reports associated with #1628 all seem to be
   associated with shares that the servermap knows about, but which aren't
   accounted for during the publish process for whatever reason. Specifically,
   it looks like the publisher is only capable of keeping track of a single
   storage server for a given share. This makes the repair process worse than
   it was pre-MDMF at updating all of the shares of a particular file to the
   newest version, and can also cause spurious UCWEs. This test simulates such
   a layout and fails if an UCWE is thrown. We need to write another test to
   ensure that all copies of a share are updated to the latest version (or
   alter this test to do that), so that the test suite doesn't pass unless both
   regressions are fixed.

   We want the publisher to follow the existing share placement when uploading
   a new version of a mutable file, and we don't want this test to pass unless
   it does.

  src/allmydata/mutable/publish.py:

   Before this commit, the publisher only kept track of a single writer for
   each share. This is insufficient to handle updates in which a single share
   may live on multiple servers. In the best case, an update will only update
   one of the existing shares instead of all of them. In some cases, the update
   will encounter the existing shares when publishing some other share,
   interpret it as a sign of an uncoordinated update, and fail. Keeping track
   of all of the writers helps ensure that all existing shares are updated, and
   helps avoid spurious uncoordinated write errors.
src/allmydata/mutable/publish.py
src/allmydata/test/no_network.py
src/allmydata/test/test_mutable.py