[tahoe-dev] what should we work on at the Boulder Hack Fest?

[Greg Troxel]

Brian Warner <warner at lothar.com> writes:

> On 3/29/12 5:41 AM, Greg Troxel wrote:
>> 
>> Your proposed plan sounds fine, but IMHO the biggest issue right now
>> is the mutable-repair-increments-version problem.
>
> Yeah, I concur.
>
> I haven't looked at that code for a long time, but it occurs to me that
> what it wants is a checker-results flag that says whether the unhealthy
> status is due to the presence of multiple versions or not. In terms of
> the ServerMap object, I think that's just:
>
>  len(sm.recoverable_versions()) + len(sm.unrecoverable_versions()) > 1
>
> We only need to do the full download+upload cycle (which increments the
> version number) if there are multiple versions present. If we're just
> missing a couple of shares (or some are corrupted and could be
> replaced), then the number of versions ==1 and we should do a
> non-incrementing form of repair.

More than that - if we have 1 share of M and  all shares of N, for N >
M, then we really just want to purge (or ignore?) the M share, and not
molest the N shares.

The test for this should be like:

  set up 5 servers S
  upload some files
  while 20 iterations
    for s in S
      take s off line
      run repair
      take s back


With the current code, you get repair every time and 100 increments, I
think.  With your proposal, I think it's still true.

The above test is how the pubgrid feels to me, or used to.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20120329/12b3b10a/attachment.pgp>