[Imported from Trac: page AccountingDesign, version 7]
parent
164ec4d359
commit
ddbc56b1b3
|
@ -168,3 +168,46 @@ authority is being delegated. The fields we'll define for v1 are:
|
||||||
exactly one lease on the resulting share.
|
exactly one lease on the resulting share.
|
||||||
* other attenuations: TBD (things like until=, SI=, UEBhash=, operation=,
|
* other attenuations: TBD (things like until=, SI=, UEBhash=, operation=,
|
||||||
max-size=)
|
max-size=)
|
||||||
|
|
||||||
|
## Lease Tables
|
||||||
|
|
||||||
|
The server will maintain a "lease table", to provide efficient lookup by
|
||||||
|
account. This primarilly supports the "how much is Bob using?" question, and
|
||||||
|
will (in a future version) support the reconcilliation operation.
|
||||||
|
|
||||||
|
To avoid revising the v1 share file format (which only offers a 4-byte
|
||||||
|
"ownerid" field), the server maintains a second table that maps from these
|
||||||
|
4-byte "pubkeyid" numbers to the full pubkey, and puts an additional column
|
||||||
|
in the lease table to map from pubkey to pubkeyid.
|
||||||
|
|
||||||
|
* `NODEDIR/accounting/pubkeyids`: 32 bytes per pubkeyid, assigned
|
||||||
|
sequentially. `pubkey[4]` is the 32 bytes at offset 4*32.
|
||||||
|
* `NODEDIR/accounting/usage/base32(PUBKEY)`: one file per pubkey.
|
||||||
|
Contents are:
|
||||||
|
* bytes 0-3: pubkeyid
|
||||||
|
* bytes 4-11: total size
|
||||||
|
* bytes 12-19: total number of files
|
||||||
|
* (deferred until v1.3): reconcilliation list (variable length list of SIs)
|
||||||
|
|
||||||
|
The lease table may be switched to use an intermediate prefix directory
|
||||||
|
later, to make lookup more efficient (some native filesystems get slow when
|
||||||
|
you put thousands or tens-of-thousands of files in a single directory).
|
||||||
|
|
||||||
|
For ext3, a 300k-entry lease table is likely to use 1.2GB . For something
|
||||||
|
like reiserfs3 that can pack small files, it might take juse 18MB. A SQL
|
||||||
|
representation would probably be fairly compact too.
|
||||||
|
|
||||||
|
### Pet Name Table
|
||||||
|
|
||||||
|
The "Usage/Aggregator" component (described below) can display a "pet name"
|
||||||
|
along with each key, to make the results more meaningful ("Bob using 73MB"
|
||||||
|
instead of "pubkey j7sta2uvcr345znqwfwlxitnii is using 73MB"). This is more
|
||||||
|
likely to be used by the friendnet case than the commercial grid (in which
|
||||||
|
this functionality will most likely exist in an external database). The "pet
|
||||||
|
name table" may contain other information about the public keys to which
|
||||||
|
storage has been delegated.
|
||||||
|
|
||||||
|
* `NODEDIR/?/petnames`: one line per pubkey, each line is:
|
||||||
|
* `base32(pubkey): PETNAME\n`
|
||||||
|
* if multiple pubkeys map to the same pet name, their usage will be added
|
||||||
|
together at display time.
|
||||||
|
|
Loading…
Reference in a new issue