mirror of
https://github.com/git/git.git
synced 2026-03-24 15:40:08 +01:00
bc39b6a796
When multiple concurrent processes try to update references in a repository they may try to lock the same lockfiles. This can happen even when the updates are non-conflicting and can both be applied, so it doesn't always make sense to abort the transaction immediately. Both the "loose" and "packed" backends thus have a grace period that they wait for the lock to be released that can be controlled via the config values "core.filesRefLockTimeout" and "core.packedRefsTimeout", respectively. The reftable backend doesn't have such a setting yet and instead fails immediately when it sees such a lock. But the exact same concepts apply here as they do apply to the other backends. Introduce a new "reftable.lockTimeout" config that controls how long we may wait for a "tables.list" lock to be released. The default value of this config is 100ms, which is the same default as we have it for the "loose" backend. Note that even though we also lock individual tables, this config really only applies to the "tables.list" file. This is because individual tables are only ever locked when we already hold the "tables.list" lock during compaction. When we observe such a lock we in fact do not want to compact the table at all because it is already in the process of being compacted by a concurrent process. So applying the same timeout here would not make any sense and only delay progress. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
57 lines
2.4 KiB
Plaintext
57 lines
2.4 KiB
Plaintext
reftable.blockSize::
|
|
The size in bytes used by the reftable backend when writing blocks.
|
|
The block size is determined by the writer, and does not have to be a
|
|
power of 2. The block size must be larger than the longest reference
|
|
name or log entry used in the repository, as references cannot span
|
|
blocks.
|
|
+
|
|
Powers of two that are friendly to the virtual memory system or
|
|
filesystem (such as 4kB or 8kB) are recommended. Larger sizes (64kB) can
|
|
yield better compression, with a possible increased cost incurred by
|
|
readers during access.
|
|
+
|
|
The largest block size is `16777215` bytes (15.99 MiB). The default value is
|
|
`4096` bytes (4kB). A value of `0` will use the default value.
|
|
|
|
reftable.restartInterval::
|
|
The interval at which to create restart points. The reftable backend
|
|
determines the restart points at file creation. Every 16 may be
|
|
more suitable for smaller block sizes (4k or 8k), every 64 for larger
|
|
block sizes (64k).
|
|
+
|
|
More frequent restart points reduces prefix compression and increases
|
|
space consumed by the restart table, both of which increase file size.
|
|
+
|
|
Less frequent restart points makes prefix compression more effective,
|
|
decreasing overall file size, with increased penalties for readers
|
|
walking through more records after the binary search step.
|
|
+
|
|
A maximum of `65535` restart points per block is supported.
|
|
+
|
|
The default value is to create restart points every 16 records. A value of `0`
|
|
will use the default value.
|
|
|
|
reftable.indexObjects::
|
|
Whether the reftable backend shall write object blocks. Object blocks
|
|
are a reverse mapping of object ID to the references pointing to them.
|
|
+
|
|
The default value is `true`.
|
|
|
|
reftable.geometricFactor::
|
|
Whenever the reftable backend appends a new table to the stack, it
|
|
performs auto compaction to ensure that there is only a handful of
|
|
tables. The backend does this by ensuring that tables form a geometric
|
|
sequence regarding the respective sizes of each table.
|
|
+
|
|
By default, the geometric sequence uses a factor of 2, meaning that for any
|
|
table, the next-biggest table must at least be twice as big. A maximum factor
|
|
of 256 is supported.
|
|
|
|
reftable.lockTimeout::
|
|
Whenever the reftable backend appends a new table to the stack, it has
|
|
to lock the central "tables.list" file before updating it. This config
|
|
controls how long the process will wait to acquire the lock in case
|
|
another process has already acquired it. Value 0 means not to retry at
|
|
all; -1 means to try indefinitely. Default is 100 (i.e., retry for
|
|
100ms).
|