package octez-internal-libs
Install
Dune Dependency
Authors
Maintainers
Sources
sha256=ddfb5076eeb0b32ac21c1eed44e8fc86a6743ef18ab23fff02d36e365bb73d61
sha512=d22a827df5146e0aa274df48bc2150b098177ff7e5eab52c6109e867eb0a1f0ec63e6bfbb0e3645a6c2112de3877c91a17df32ccbff301891ce4ba630c997a65
doc/irmin_pack_unix/Irmin_pack_unix/Pack_key/index.html
Module Irmin_pack_unix.Pack_key
Source
The type of keys referencing values stored in the irmin-pack
backend.
type ('hash, _) unsafe_state = private
| Direct : {
hash : 'hash;
offset : Optint.Int63.t;
length : int;
volume_identifier : Lower.volume_identifier option;
} -> ('hash, safe) unsafe_state
(*A "direct" pointer to a value stored at
offset
in the pack-file (with hashhash
and lengthlength
). Such keys can be dereferenced from the store with a single IO read, without needing to consult the index.They are built in-memory (e.g. after adding a fresh value to the pack file), but have no corresponding encoding format, as the pack format keeps length information with the values themselves.
When decoding a inode, which references its children as single offsets, we fetch the length information of the child at the same time as fetching its hash (which we must do anyway in order to do an integrity check), creating keys of this form.
*)| Indexed : 'hash -> ('hash, safe) unsafe_state
(*A pointer to an object in the pack file that is indexed. Reading the object necessitates consulting the index, after which the key can be promoted to
Direct
.Such keys result from decoding pointers to other store objects (nodes or commits) from commits or from the branch store.
*)| Offset : Optint.Int63.t -> ('hash, unsafe) unsafe_state
(*Same as
*)Direct
, but the hash and length of the object have not been fetched. Only used to speed up the GC traversal.
Undereferencable keys
A key k
is "undereferencable" with respect to some store handle t
if find t k <> Some _
. Such keys should not arise during regular operation of a single Irmin repository, but are still technically constructible in the following ways:
- storage corruption. When decoding a key from disk, we may not immediately check that it is dereferenceable for performance reasons. In this case, any corruption to the key (or the referenced section of the store) will be discovered on attempted
find
(ormem
).
- passing keys between store handles. Read-only handles on a pack store must explicitly reload to observe recent writes to the store. This means that any keys built by a read-write instance and passed to a read-only instance will be undereferencable until that reader has reloaded.
- passing keys between repositories. Keys created for one Irmin repository may not be dereferenced with respect to another by design.
val v_direct :
offset:Optint.Int63.t ->
length:int ->
?volume_identifier:Lower.volume_identifier ->
'h ->
'h t
val promote_exn :
offset:Optint.Int63.t ->
length:int ->
?volume_identifier:Lower.volume_identifier ->
'h t ->
unit
val set_volume_identifier_exn :
volume_identifier:Lower.volume_identifier option ->
'h t ->
unit