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

[Brian Warner]

On 7/11/12 9:17 PM, David-Sarah Hopwood wrote:
> On 11/07/12 16:17, Brian wrote:
>>
>> So maybe backups *aren't* appropriate, or at least when we restore
>> from a backup, we should still add starter leases to all shares (but
>> also preserve the leases from the backup, for accounting purposes).
> 
> Consider the case where the ownership has changed. The old owner
> shouldn't be able to cancel the new lease. So maybe it should just be
> treated as a starter lease, in which case we don't get any benefit
> from restoring the backup, I think.

Yeah. I think there's still value to keeping the data around (i.e. don't
delete the whole DB as soon as you realize something changed while you
weren't looking), but clearly we can't safely *not* add a starter lease,
even for shares that already have leases.

So I guess the rule is: if the leasedb is ever inconsistent (i.e.
restored from a backup), all shares found during the next crawl need to
get a starter lease. What if we create a "lease db generation counter",
incremented each time we've lost time (I think of restore-from-backup
like being asleep while some changes happened, so you wake up and
realize that time as passed while you weren't looking). Each share has a
starter-lease-generation-counter field. If the share's value is smaller
than the DB's value (or missing, which covers the initial-bringup case),
we add a starter lease and update the share's generation counter.

I'm not 100% sure we can detect gaps in the timeline, though. Maybe we
could do it with a "DB is dirty" flag, set at startup, cleared after the
RIStorageServer has stopped accepting requests, if we see it set at
startup then we rev the generation-counter and the crawler will start
adding starter-leases. Not crash-only, but it serves exactly the same
purpose as a regular FS dirty flag (avoiding expensive recovery work in
the common case of clean shutdown).

cheers,
 -Brian