#332 closed defect (invalid)

K=1 for mutable files

Reported by: zooko Owned by: warner
Priority: major Milestone: undecided
Component: code-mutable Version: 0.8.0
Keywords: Cc: zooko
Launchpad Bug:


Per [this dicussion http://allmydata.org/pipermail/tahoe-dev/2008-March/000416.html], we're changing mutable files to have K=1.

Some documentation needs to be updated. See also #254 (need better user output on UncoordinatedWriteError?) and #207 (unit tests for failure modes of small mutable files).

Change History (10)

comment:1 Changed at 2008-03-08T01:45:59Z by warner

Also, we need to fix #312 before we change K, otherwise we risk data unavailability for existing files (which are encoded at 3-of-10).

comment:2 Changed at 2008-03-10T19:38:32Z by zooko

We hesitate to make this change until #207 (unit tests for failure modes of small mutable files) is in place to assure us that this change doesn't destroy any data from the 0.8.0-based Allmydata.com 3.0 beta production grid.

comment:3 Changed at 2008-03-10T20:30:20Z by warner

Oh, another concern with k=1 is that this makes it a lot easier to experience an accidental rollback attack when a single server is offline during an update. Specifically:

  • I'm experimenting with 1-of-8, since that gets the availability that I want (relative to the old 3-of-10)
  • the mutfilenode is created, and ver1 shares are pushed to 8 servers
  • later, we update to ver2, but one of the servers is offline at that moment
    • ver2 shares go to 7 of the original servers and one new one.
  • now the offline server comes back. We now have 8 ver2 shares and 1 ver1 share
  • now a retrieve occurs. If it hits the once-offline server first, we'll finish with ver1, and the accidental rollback will have occurred.

If a server was offline, then the chances of experiencing a rollback are 1-out-of-8 (since it requires that the fastest server in the later retrieval group be the one with the old version).

When we refactor Retrieve to grab multiple versions (#205), we plan to introduce the "epsilon" parameter as protection against both this and intentional rollback attacks. But we're likely to switch to k=1 before we finish that work.

comment:4 Changed at 2008-03-12T15:50:10Z by zooko

  • Milestone changed from 0.9.0 (Allmydata 3.0 final) to undecided

If I understand correctly, we're pushing this one out of v0.9.0.

comment:5 Changed at 2008-03-12T15:56:15Z by zooko

If we change the Prime Directive of Uncoordinated Writes: "Don't Do That", then we also need to change the user output that is visible from the wui on UncoordinatedWriteError?, as was described in now-closed ticket #254 (need better user output on UncoordinatedWriteError?).

comment:6 Changed at 2008-05-30T04:46:23Z by zooko

  • Owner changed from nobody to warner

I think we've given up on the idea of using {K=1} at all. Let's close this as invalid or wontfix or fixed. :-)

comment:7 Changed at 2008-05-31T00:15:44Z by zooko

  • Milestone changed from undecided to 1.1.0

Putting this into Milestone 1.1.0 so that Brian will notice it. Justification: this was a proposed robustness improvement to mutable files which was obviated by Brian's excellent "new mutable files" work which is going into 1.1.0.

comment:8 Changed at 2008-06-03T06:13:43Z by warner

  • Milestone changed from 1.1.0 to undecided

This is definitely not a 1.1.0 thing.

I think there may still be value in switching to K=1. It needs more testing than we can give it this week, and it's lower priority that anything we have in the next month. Giving up on it requires some thinking time, and there are higher-priority demands on thinking time right now. So, having noticed it, I'm going to move it all the way back out to the Undecided category.

comment:9 Changed at 2008-06-03T06:13:56Z by warner

  • Component changed from unknown to code-mutable

comment:10 Changed at 2008-09-24T13:20:31Z by zooko

  • Resolution set to invalid
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.