[tahoe-lafs-trac-stream] [tahoe-lafs] #666: Accounting: limit storage space used by different parties

[tahoe-lafs]

#666: Accounting: limit storage space used by different parties
------------------------------+------------------------
     Reporter:  warner        |      Owner:
         Type:  task          |     Status:  new
     Priority:  major         |  Milestone:  2.0.0
    Component:  code-storage  |    Version:  1.3.0
   Resolution:                |   Keywords:  accounting
Launchpad Bug:                |
------------------------------+------------------------

Comment (by davidsarah):

 Replying to [comment:11 zooko]:
 > https://github.com/davidsarah/tahoe-
 lafs/blob/666-accounting/src/allmydata/storage/leasedb.py#L223 says
 "delete leases first to maintain integrity constraint", but there isn't
 actually an invariant that a lease exists only if a share exists -- that
 invariant would be broken by the user rm'ing a share externally.

 There is an invariant that leases exist only for shares that exist *in the
 database*:
 {{{
 CREATE TABLE `leases` ( ...
  FOREIGN KEY (`storage_index`, `shnum`) REFERENCES `shares`
 (`storage_index`, `shnum`),
 ... )
 }}}
 rm'ing the share externally doesn't break that invariant: the
 !AccountingCrawler (when finished) will delete.

 > Also, shouldn't it check that the share is already marked as
 {{{"going"}}}, and raise an exception if not?

 No, because if the !AccountingCrawler notices that a share has disappeared
 unexpectedly from backend storage, it will delete the share entry (and any
 leases) from the database without it ever being in STATE_GOING.
 STATE_GOING is for when we've sent a request to a remote backend for it to
 delete the objects representing share chunks, but have not received
 confirmation that all such objects have been deleted.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/666#comment:15>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage