blocks.store.buffer
Logical block storage which uses two backing stores to implement a buffer.
New blocks are written to the buffer store, which can be flushed to write all of the blocks to the primary store. Reads return a unified view of the existing and buffered blocks.
Logical block storage which uses two backing stores to implement a buffer. New blocks are written to the _buffer_ store, which can be flushed to write all of the blocks to the _primary_ store. Reads return a unified view of the existing and buffered blocks.
blocks.store.cache
Cache stores provide logical block storage backed by two other stores, a primary store and a cache. Blocks are added to the cache on reads and writes, and evicted with a least-recently-used strategy to keep the cache under a certain total size. Operations on this store will prefer to look up blocks in the cache, and fall back to the primary store when not available.
Because the caching logic runs locally, the backing cache storage should not be shared among multiple concurrent processes.
Cache stores provide logical block storage backed by two other stores, a _primary store_ and a _cache_. Blocks are added to the cache on reads and writes, and evicted with a least-recently-used strategy to keep the cache under a certain total size. Operations on this store will prefer to look up blocks in the cache, and fall back to the primary store when not available. Because the caching logic runs locally, the backing cache storage should not be shared among multiple concurrent processes.
blocks.store.file
This store provides block storage backed by files in local directories. Each
block is stored in a separate file. File block stores may be constructed
using the file://<path-to-root-dir> URI form. Under the root directory, the
store keeps a block files in a subdirectory, alongside some layout metadata
and a directory.
$ROOT/meta.properties
$ROOT/blocks/111497df/35011497df3588b5a3...
$ROOT/landing/block.123456789.tmp
In many filesystems, performance degrades as the number of files in a directory grows. In order to reduce this impact and make navigating the blocks more efficient, block files are stored in multiple subdirectories consisting of the first four bytes of the multihashes of the blocks stored in them. Within each directory, blocks are stored in files whose names consist of the rest of their digests.
In addition to the blocks, a meta.properties file at the root holds
information about the current storage layout for future-proofing. This
currently holds a single property, the layout version, which is always
"1".
This store provides block storage backed by files in local directories. Each
block is stored in a separate file. File block stores may be constructed
using the `file://<path-to-root-dir>` URI form. Under the root directory, the
store keeps a block files in a subdirectory, alongside some layout metadata
and a directory.
$ROOT/meta.properties
$ROOT/blocks/111497df/35011497df3588b5a3...
$ROOT/landing/block.123456789.tmp
In many filesystems, performance degrades as the number of files in a
directory grows. In order to reduce this impact and make navigating the
blocks more efficient, block files are stored in multiple subdirectories
consisting of the first four bytes of the multihashes of the blocks stored in
them. Within each directory, blocks are stored in files whose names consist
of the rest of their digests.
In addition to the blocks, a `meta.properties` file at the root holds
information about the current storage layout for future-proofing. This
currently holds a single property, the layout version, which is always
`"1"`.blocks.store.memory
Block storage backed by a map in an atom. Blocks put into this store will be
passed to load! to ensure the content resides in memory. Memory block stores
may be constructed usin the mem:- URI form.
This store is most suitable for testing, caches, and other situations which call for a non-persistent block store.
Block storage backed by a map in an atom. Blocks put into this store will be passed to `load!` to ensure the content resides in memory. Memory block stores may be constructed usin the `mem:-` URI form. This store is most suitable for testing, caches, and other situations which call for a non-persistent block store.
blocks.store.replica
Logical block storage which writes to multiple backing stores to ensure durability. Lookups will try the backing stores in order to find blocks.
Logical block storage which writes to multiple backing stores to ensure durability. Lookups will try the backing stores in order to find blocks.
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close