| | 171 | |
| | 172 | == Lease Tables == |
| | 173 | |
| | 174 | The server will maintain a "lease table", to provide efficient lookup by |
| | 175 | account. This primarilly supports the "how much is Bob using?" question, and |
| | 176 | will (in a future version) support the reconcilliation operation. |
| | 177 | |
| | 178 | To avoid revising the v1 share file format (which only offers a 4-byte |
| | 179 | "ownerid" field), the server maintains a second table that maps from these |
| | 180 | 4-byte "pubkeyid" numbers to the full pubkey, and puts an additional column |
| | 181 | in the lease table to map from pubkey to pubkeyid. |
| | 182 | |
| | 183 | * {{{NODEDIR/accounting/pubkeyids}}}: 32 bytes per pubkeyid, assigned |
| | 184 | sequentially. {{{pubkey[4]}}} is the 32 bytes at offset 4*32. |
| | 185 | * {{{NODEDIR/accounting/usage/base32(PUBKEY)}}}: one file per pubkey. |
| | 186 | Contents are: |
| | 187 | * bytes 0-3: pubkeyid |
| | 188 | * bytes 4-11: total size |
| | 189 | * bytes 12-19: total number of files |
| | 190 | * (deferred until v1.3): reconcilliation list (variable length list of SIs) |
| | 191 | |
| | 192 | The lease table may be switched to use an intermediate prefix directory |
| | 193 | later, to make lookup more efficient (some native filesystems get slow when |
| | 194 | you put thousands or tens-of-thousands of files in a single directory). |
| | 195 | |
| | 196 | For ext3, a 300k-entry lease table is likely to use 1.2GB . For something |
| | 197 | like reiserfs3 that can pack small files, it might take juse 18MB. A SQL |
| | 198 | representation would probably be fairly compact too. |
| | 199 | |
| | 200 | === Pet Name Table === |
| | 201 | |
| | 202 | The "Usage/Aggregator" component (described below) can display a "pet name" |
| | 203 | along with each key, to make the results more meaningful ("Bob using 73MB" |
| | 204 | instead of "pubkey j7sta2uvcr345znqwfwlxitnii is using 73MB"). This is more |
| | 205 | likely to be used by the friendnet case than the commercial grid (in which |
| | 206 | this functionality will most likely exist in an external database). The "pet |
| | 207 | name table" may contain other information about the public keys to which |
| | 208 | storage has been delegated. |
| | 209 | |
| | 210 | * {{{NODEDIR/?/petnames}}}: one line per pubkey, each line is: |
| | 211 | * {{{base32(pubkey): PETNAME\n}}} |
| | 212 | * if multiple pubkeys map to the same pet name, their usage will be added |
| | 213 | together at display time. |