mhtirogla
Home
Systems
API
Pricing
About
Log in
← Back
Home
›
Systems
›
Operating systems and runtimes
filesystem
local file system
ext4, ZFS, APFS
System
Techniques · 4
Primitives · 24
filesystem
Copy on write b tree
storage · medium: Append-only/shadow-paging B+tree: copy the root-to-leaf path on write, atomic root swap (LMDB style)
Crash consistency ordering
storage · medium: Ordered writes, barriers and FUA so on-disk state is valid after power loss at any point
Erasure coding
storage · medium: Reed-Solomon k+m coding to survive m lost shards at lower overhead than replication
Adaptive replacement cache
systems · medium: ARC: balances recency and frequency lists with ghost entries; self-tuning, scan-resistant cache
fsync, O_DSYNC and O_DIRECT
hardware-os · low: What fsync, fdatasync, O_DSYNC, O_DIRECT and F_FULLFSYNC really guarantee on Linux and macOS, and the exact call sequences for crash-safe files.
›
B+ tree
storage · low: Balanced high-fanout search tree with all values in linked leaves; the default on-disk index for point lookups and range scans.
›
Free space management
storage · low: Free-space bitmaps, extent B-trees and space maps; allocation policies and fragmentation
Write-ahead log
storage · low: Append each change to a checksummed sequential log and fsync it before touching data pages; the basis of crash durability in nearly every database.
›
LZ4
compression · low: Byte-aligned LZ77 with no entropy stage; compresses at hundreds of MB/s and decompresses at several GB/s per core, for when speed beats ratio.
›
Zstandard (zstd)
compression · low: LZ77 plus Huffman and FSE entropy coding, with levels from LZ4-like speed to xz-like ratio, all decoding at about 1-2 GB/s.
›
RCU (read-copy-update)
concurrency · low: Readers access shared data with no locks or atomic writes; writers publish a new copy and free the old one after a grace period.
›
Merkle tree
data-structures · low: Hash tree for verifying and diffing large datasets with logarithmic proofs
CRC32C checksums
hardware-os · low: The Castagnoli CRC-32 with dedicated instructions on x86 (SSE4.2) and ARMv8. It is the standard fast integrity check for storage blocks, logs and network frames.
›
mmap and the page cache
hardware-os · low: How read() and mmap reach file data through the kernel page cache, what readahead and madvise do, and why databases use their own buffer pool instead.
›
SSD and NVMe internals
hardware-os · low: NAND pages and erase blocks, the FTL, garbage collection and write amplification, NVMe queues and queue depth, and 4 KiB alignment, with the numbers that matter.
›
Content-addressed storage
storage · low: Store each blob under the hash of its bytes: immutable, deduplicated by construction, self-verifying on every read, and composable into Merkle trees.
›
Extent trees
storage · low: Map file ranges to disk extents in a shallow B-tree (ext4, XFS)
Atomic file replacement
hardware-os · low: Write temp file, fsync, rename over target, fsync directory: crash-safe whole-file updates
SIMD programming
hardware-os · low: Process 4-16 lanes per instruction with AVX2, AVX-512 or NEON via Rust std::arch, with runtime dispatch and a portable fallback.
›
Finite field arithmetic
numerics · low: Prime-field and extension-field arithmetic (Montgomery form, Goldilocks, BabyBear), vectorized
+ 8 more primitives
System
Techniques · 4
Primitives · 24
filesystem
Copy on write b tree
storage · medium: Append-only/shadow-paging B+tree: copy the root-to-leaf path on write, atomic root swap (LMDB style)
Crash consistency ordering
storage · medium: Ordered writes, barriers and FUA so on-disk state is valid after power loss at any point
Erasure coding
storage · medium: Reed-Solomon k+m coding to survive m lost shards at lower overhead than replication
Adaptive replacement cache
systems · medium: ARC: balances recency and frequency lists with ghost entries; self-tuning, scan-resistant cache
fsync, O_DSYNC and O_DIRECT
hardware-os · low: What fsync, fdatasync, O_DSYNC, O_DIRECT and F_FULLFSYNC really guarantee on Linux and macOS, and the exact call sequences for crash-safe files.
›
B+ tree
storage · low: Balanced high-fanout search tree with all values in linked leaves; the default on-disk index for point lookups and range scans.
›
Free space management
storage · low: Free-space bitmaps, extent B-trees and space maps; allocation policies and fragmentation
Write-ahead log
storage · low: Append each change to a checksummed sequential log and fsync it before touching data pages; the basis of crash durability in nearly every database.
›
LZ4
compression · low: Byte-aligned LZ77 with no entropy stage; compresses at hundreds of MB/s and decompresses at several GB/s per core, for when speed beats ratio.
›
Zstandard (zstd)
compression · low: LZ77 plus Huffman and FSE entropy coding, with levels from LZ4-like speed to xz-like ratio, all decoding at about 1-2 GB/s.
›
RCU (read-copy-update)
concurrency · low: Readers access shared data with no locks or atomic writes; writers publish a new copy and free the old one after a grace period.
›
Merkle tree
data-structures · low: Hash tree for verifying and diffing large datasets with logarithmic proofs
CRC32C checksums
hardware-os · low: The Castagnoli CRC-32 with dedicated instructions on x86 (SSE4.2) and ARMv8. It is the standard fast integrity check for storage blocks, logs and network frames.
›
mmap and the page cache
hardware-os · low: How read() and mmap reach file data through the kernel page cache, what readahead and madvise do, and why databases use their own buffer pool instead.
›
SSD and NVMe internals
hardware-os · low: NAND pages and erase blocks, the FTL, garbage collection and write amplification, NVMe queues and queue depth, and 4 KiB alignment, with the numbers that matter.
›
Content-addressed storage
storage · low: Store each blob under the hash of its bytes: immutable, deduplicated by construction, self-verifying on every read, and composable into Merkle trees.
›
Extent trees
storage · low: Map file ranges to disk extents in a shallow B-tree (ext4, XFS)
Atomic file replacement
hardware-os · low: Write temp file, fsync, rename over target, fsync directory: crash-safe whole-file updates
SIMD programming
hardware-os · low: Process 4-16 lanes per instruction with AVX2, AVX-512 or NEON via Rust std::arch, with runtime dispatch and a portable fallback.
›
Finite field arithmetic
numerics · low: Prime-field and extension-field arithmetic (Montgomery form, Goldilocks, BabyBear), vectorized
Reed-Solomon codes
signal-processing · low: Byte-oriented MDS code: n-k parity symbols correct (n-k)/2 unknown symbol errors or n-k known erasures; the workhorse for bursts, QR codes, discs and storage.
›
Swiss table
data-structures · low: Open-addressing hash table that filters 8-16 slots at once with 1-byte hash tags and SIMD, giving fast lookups at 87.5 % load.
›
LRU and CLOCK
systems · low: LRU evicts the least recently used entry via hash map plus linked list; CLOCK approximates it with a reference bit, so hits take no lock.
›
Memory ordering
concurrency · low: What Relaxed, Acquire, Release and SeqCst atomics actually guarantee, what they cost on x86 and ARM, and which one each pattern needs.
›
Merkle dag
data-structures · low: Content-addressed DAG of hashed nodes (git trees/commits) for dedupe and verifiable history
Nvme queues
hardware-os · low: NVMe submission and completion queue pairs, doorbells and polling from a driver
Virtual memory and the TLB
hardware-os · low: How page tables and TLBs translate every address, what TLB reach means, and when 2 MiB or 1 GiB huge pages pay off on Linux.
›
Cryptographic hashes (SHA-2, BLAKE3)
security · low: Collision-resistant fingerprints of data; SHA-256 for interoperability, BLAKE3 for speed, HMAC/HKDF for keyed uses.
›
Copy for AI
Similar systems
Share the most building blocks with this one.
btree-engine
27 %
storage-array
24 %
backup-dr
23 %
block-storage
22 %
audit-log
21 %