| 1 | reftable.blockSize:: |
| 2 | The size in bytes used by the reftable backend when writing blocks. |
| 3 | The block size is determined by the writer, and does not have to be a |
| 4 | power of 2. The block size must be larger than the longest reference |
| 5 | name or log entry used in the repository, as references cannot span |
| 6 | blocks. |
| 7 | + |
| 8 | Powers of two that are friendly to the virtual memory system or |
| 9 | filesystem (such as 4kB or 8kB) are recommended. Larger sizes (64kB) can |
| 10 | yield better compression, with a possible increased cost incurred by |
| 11 | readers during access. |
| 12 | + |
| 13 | The largest block size is `16777215` bytes (15.99 MiB). The default value is |
| 14 | `4096` bytes (4kB). A value of `0` will use the default value. |
| 15 | |
| 16 | reftable.restartInterval:: |
| 17 | The interval at which to create restart points. The reftable backend |
| 18 | determines the restart points at file creation. Every 16 may be |
| 19 | more suitable for smaller block sizes (4k or 8k), every 64 for larger |
| 20 | block sizes (64k). |
| 21 | + |
| 22 | More frequent restart points reduces prefix compression and increases |
| 23 | space consumed by the restart table, both of which increase file size. |
| 24 | + |
| 25 | Less frequent restart points makes prefix compression more effective, |
| 26 | decreasing overall file size, with increased penalties for readers |
| 27 | walking through more records after the binary search step. |
| 28 | + |
| 29 | A maximum of `65535` restart points per block is supported. |
| 30 | + |
| 31 | The default value is to create restart points every 16 records. A value of `0` |
| 32 | will use the default value. |
| 33 | |
| 34 | reftable.indexObjects:: |
| 35 | Whether the reftable backend shall write object blocks. Object blocks |
| 36 | are a reverse mapping of object ID to the references pointing to them. |
| 37 | + |
| 38 | The default value is `true`. |
| 39 | |
| 40 | reftable.geometricFactor:: |
| 41 | Whenever the reftable backend appends a new table to the stack, it |
| 42 | performs auto compaction to ensure that there is only a handful of |
| 43 | tables. The backend does this by ensuring that tables form a geometric |
| 44 | sequence regarding the respective sizes of each table. |
| 45 | + |
| 46 | By default, the geometric sequence uses a factor of 2, meaning that for any |
| 47 | table, the next-biggest table must at least be twice as big. A maximum factor |
| 48 | of 256 is supported. |
| 49 | |
| 50 | reftable.lockTimeout:: |
| 51 | Whenever the reftable backend appends a new table to the stack, it has |
| 52 | to lock the central "tables.list" file before updating it. This config |
| 53 | controls how long the process will wait to acquire the lock in case |
| 54 | another process has already acquired it. Value 0 means not to retry at |
| 55 | all; -1 means to try indefinitely. Default is 100 (i.e., retry for |
| 56 | 100ms). |