[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2204: cloud branch: allmydata.storage.leasedb.NonExistentShareError

[Tahoe-LAFS]

#2204: cloud branch: allmydata.storage.leasedb.NonExistentShareError
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  exarkun
  CyberAxe               |
         Type:  defect   |     Status:  assigned
     Priority:  normal   |  Milestone:  undecided
    Component:  code-    |    Version:  cloud-branch
  storage                |   Keywords:  renew leases leasedb blocks-cloud-
   Resolution:           |  merge
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by exarkun):

 I've encountered this now as well.

 The comment about starting with a new SQLite3 lease database is
 appreciated - that agrees with my situation and supports my hypothesis
 about what's going wrong here.

 My understanding of the `shares` table of the lease database is that it is
 populated in one of two ways:

 1. A new share is created.
 2. The accounting crawler finds a share not in the lease database.

 The code is all meant to tolerate lose of the lease database, too.

 When `_locked_testv_and_readv_and_writev` is done applying writes, it
 attempts to `add_or_renew_default_lease` for the share (via the account).
 This eventually calls down to `add_or_renew_leases` on the lease database.
 `add_or_renew_leases` requires that the share being leased already exists
 in the `shares` table.

 So, if the lease database is ever lost, there is a period while the
 accounting crawler is re-populating the `shares` table when it is not
 possible to write to mutable files.

 Because the problem depends on both the implementation of mutable storage,
 the accounting system, the lease database, and on an external event
 causing the loss of the lease database, it's not clear to me what testing
 approach will work.

 Also, the implementation of `_locked_testv_and_readv_and_writev` is
 sufficiently complex that the idea of touching it at all is pretty scary.
 It seems like a reasonable fix would be to cause it to _always_
 `account.add_share` before `_update_lease` (rather than the current
 behavior of only `account.add_share`ing if `shnum not in sharemap`).

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2204#comment:10>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage