[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.
|
||||
* other attenuations: TBD (things like until=, SI=, UEBhash=, operation=,
|
||||
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