package irmin-pack

You can search for identifiers within the package.

in-package search v0.2.0

Irmin backend which stores values in a pack file

Install

Dune Dependency

github.com Readme Changelog ISC License Edit opam file Versions (44)

Authors

T

Thomas Gazagnaire

Maintainers

T

thomas@gazagnaire.org

Sources

irmin-3.4.2.tbz

sha256=964512f77697947a73dd1875c634d6804e98f14167c5aadd3c4f85b5f30ffb53

sha512=d56d3285daa2dd36f1eaff867af5c8f44c61bba4de1a5c7bb5347652dbc460c343483ab61de1a9302f664af357eacc964dc5c8b4477f6d01372dc028b162e98b

doc/irmin-pack.unix/Irmin_pack_unix/Pack_key/index.html

Module `Irmin_pack_unix.Pack_key`Source

Sourcetype 'hash t

The type of keys referencing values stored in the irmin-pack backend.

Sourcetype 'hash state = private

| Direct of {
1. hash : 'hash;
2. offset : Optint.Int63.t;
3. length : int;
}
(*
A "direct" pointer to a value stored at offset in the pack-file (with hash hash and length length). 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 of 'hash
(*
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.
*)

The internal state of a key (read with inspect).

Invariant: keys of the form Indexed always reference values that have entries in the index (as otherwise these keys could not be dereferenced).

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 (or mem).

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.

Sourceval inspect : 'hash t -> 'hash state

Sourceval v_direct : hash:'h -> offset:Optint.Int63.t -> length:int -> 'h t

Sourceval v_indexed : 'h -> 'h t

Sourceval promote_exn : 'h t -> offset:Optint.Int63.t -> length:int -> unit

Sourcemodule type S = sig ... end

Sourcemodule Make (Hash : Irmin.Hash.S) : S with type hash = Hash.t

Sourcemodule type Store_spec = sig ... end

Sourcemodule Store_spec : Store_spec

On This Page

Undereferencable keys