[tahoe-dev] configuring sqlite efficiency and durability

[David-Sarah Hopwood]

On 04/12/12 04:22, Brian wrote:
> On 12/3/12 6:13 PM, Zooko Wilcox-O'Hearn wrote:
> 
>> In fact, as David-Sarah pointed out today, since we update the leasedb
>> and then write out the full share data before acking on file upload,
>> the window of opportunity for this failure is probably zero on file
>> upload.
> 
> Hm, we should probably analyze what happens with races in the "INCOMING"
> state, as new shares are being written to disk or S3. If I remember the
> plan correctly, we do:
> 
>  1: leasedb.write state=INCOMING (atomic)
>  2: write share to storage (non-atomic)
>  3: leasedb.write state=PRESENT (atomic)

The states are called COMING and STABLE, but yes.

> and if we ever see a surprising share in the INCOMING state, we assume
> that it's partially-written and should therefore delete it.

I think so, yes. That's not currently implemented.

> If a kernel crash causes the leasedb to rollback to state=INCOMING after
> step 3, then I guess we'd delete a perfectly valid share. If it rolls
> back all the way to step 0 (i.e. no entry in the leasedb), then the
> surprise share would get a starter lease, right?

That depends whether we have periodic checking for shares that need
starter leases, or whether the scan for such shares has to be triggered
manually.

-- 
David-Sarah Hopwood ⚥

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20121204/babe2b7f/attachment.pgp>