[tahoe-dev] weekly Tahoe dev call report: 2012-07-10

[Brian Warner]

On 7/11/12 8:27 AM, Terrell Russell wrote:

> Leases are per-share? And not per file... so "#6, share deleted" is
> still only 1 of N being deleted...

Right, leases are per-share. The idea was that rebalancing (which really
wants to move share #6 from server A to server B) is being driven by a
client who has the right (Accounting) to add share #6 to server A, but
not the right to delete share #6 from server B. They *do* have the right
to stop keeping 6-on-B alive, though, by cancelling their existing lease
and not creating/renewing any others. If they're the only person
interested in this file, 6-on-B can get GCed right away.

The hope is that multiple supporters of a shared file will all converge
on the same rebalancing conclusions, and allow the
should-be-deleted-but-our-authority-model-doesn't-make-that-easy share
to just expire.

> Are leases (across the N servers) managed independently enough that a
> repairer would be able to recover lost shares?

Yeah, I think so. The repairer is basically just a smart uploader: it
can create leases on individual shares (including new ones) just like
the original uploader. It downloads enough shares to reconstruct the
ciphertext, then builds as many new shares as it needs from that, then
puts them in the right places, and establishes leases on them.
(uploading a share automatically creates a lease on it.. no race
condition there).


cheers,
 -Brian