<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Storage on Momo Engineering Journal</title><link>/categories/storage/</link><description>Recent content in Storage on Momo Engineering Journal</description><image><title>Momo Engineering Journal</title><url>/images/og-image.png</url><link>/images/og-image.png</link></image><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 28 Oct 2026 17:47:15 -0600</lastBuildDate><atom:link href="/categories/storage/index.xml" rel="self" type="application/rss+xml"/><item><title>S3 Lifecycle Rules on a Content-Addressed Store: Time as a First-Class Dimension</title><link>/posts/058-s3-lifecycle-on-cas/</link><pubDate>Wed, 21 Oct 2026 03:35:13 +0000</pubDate><guid>/posts/058-s3-lifecycle-on-cas/</guid><description>Lifecycle rules are the first feature that makes momo delete data on a schedule rather than on request — which turns age, storage class, and delete markers into correctness problems. This post walks through the expiration and transition engine, why a background worker is the only safe place to run it, and how expiration composes with versioning&amp;rsquo;s delete markers.</description></item><item><title>S3 Versioning on a Content-Addressed Store: Two Kinds of Identity</title><link>/posts/056-s3-versioning-on-cas/</link><pubDate>Sun, 11 Oct 2026 08:56:13 +0000</pubDate><guid>/posts/056-s3-versioning-on-cas/</guid><description>Why S3 versioning and content-addressed storage seem to conflict — mutation identity vs content identity — and how momo keeps both: UUIDv4 version records pointing at deduplicated blobs, delete markers that shadow without deleting, and pagination that can only be computed after sorting. Teaches: the real semantics backup tools depend on, and where the version chain deliberately stops being distributed.</description></item><item><title>Packing Small Objects into Superblocks: O(1) Reads Without Per-Blob Inodes</title><link>/posts/055-adaptive-volume-storage/</link><pubDate>Tue, 06 Oct 2026 02:44:44 +0000</pubDate><guid>/posts/055-adaptive-volume-storage/</guid><description>Why millions of small files per directory collapse a filesystem, and how a SeaweedFS-style volume layout fixes it: append-only superblocks, 8-byte-aligned needles with CRC32C frames, hole-punching deletion, and crash recovery by truncation. Teaches: the real cost of per-blob files, why alignment beats variable-length framing, and how to make crash recovery O(1).</description></item><item><title>Reducing Read-Verify Hashing: Trust Earned by Real Verification</title><link>/posts/043-reduce-read-verify-hashing/</link><pubDate>Wed, 26 Aug 2026 19:00:59 +0000</pubDate><guid>/posts/043-reduce-read-verify-hashing/</guid><description>Verify-on-read re-hashes the full object on every local read (~8x slower than write). A ReadVerifier seam skips re-verification for blobs verified this process, while scrub still catches bitrot.</description></item><item><title>Rotating Secrets Without a Secret Server: Deriving, Versioning, and Hot-Reloading Keys</title><link>/posts/054-secrets-management-key-rotation/</link><pubDate>Tue, 25 Aug 2026 03:25:35 +0000</pubDate><guid>/posts/054-secrets-management-key-rotation/</guid><description>How momo manages encryption keys without a central secret server: a pluggable provider chain (env, then config file), a per-node versioned key registry in local storage, and rotation that promotes a new key without any downtime. Teaches: why a provider chain beats a single source, how key versioning enables online rotation, and when rotation is and is not worth the complexity.</description></item><item><title>Tenant Isolation: Deriving Per-Tenant Keys, Enforcing ACLs, and Proving What Happened</title><link>/posts/053-multitenancy-authorization-audit/</link><pubDate>Tue, 25 Aug 2026 03:25:29 +0000</pubDate><guid>/posts/053-multitenancy-authorization-audit/</guid><description>How momo isolates tenants without a central secret server: HKDF-derived per-tenant keys, default-deny ACLs evaluated per request, and a SHA-256 hash-chained audit log that makes tampering detectable. Teaches: key derivation vs. key storage, why ACL evaluation order matters, and how hash chaining turns a log into evidence.</description></item><item><title>At-Rest Integrity: Verify-on-Read, Checksums, and GC</title><link>/posts/007-at-rest-integrity-and-gc/</link><pubDate>Mon, 24 Aug 2026 19:36:43 +0000</pubDate><guid>/posts/007-at-rest-integrity-and-gc/</guid><description>CAS keys make verify-on-read free: central verification, x-amz-checksum echo, tombstone GC, and corruption surfacing.</description></item><item><title>Centralized Integrity Verification: Checksums Move to the Storage Core</title><link>/posts/031-core-integrity-verification/</link><pubDate>Mon, 24 Aug 2026 18:03:31 +0000</pubDate><guid>/posts/031-core-integrity-verification/</guid><description>S3 integrity checksums moved from a surface-level adapter into the storage/ingest core via a protocol-agnostic ChecksumProvider seam — every write path verified, replicas re-verify on receive.</description></item><item><title>Pluggable Storage Backends: local, nfs, s3, raw</title><link>/posts/006-pluggable-storage-backends/</link><pubDate>Sun, 26 Jul 2026 14:33:59 +0000</pubDate><guid>/posts/006-pluggable-storage-backends/</guid><description>The &lt;code&gt;[storage] backend&lt;/code&gt; seam swaps blob storage (local, nfs, s3, raw) behind one Store interface, keeping CAS metadata local.</description></item><item><title>CRUSH-lite: Deterministic Weighted Placement</title><link>/posts/005-crush-placement/</link><pubDate>Tue, 30 Jun 2026 13:09:01 +0000</pubDate><guid>/posts/005-crush-placement/</guid><description>Weighted rendezvous hashing picks replicas deterministically and peer-equally without a central allocator — later hardened for failure domains. Teaches: content-hash-based placement, weighted rendezvous hashing, deterministic stable sort, failure domain filtering.</description></item><item><title>CAS: Content-Addressable Storage and Deduplication</title><link>/posts/004-cas-content-addressable-store/</link><pubDate>Wed, 11 Mar 2026 14:34:18 +0000</pubDate><guid>/posts/004-cas-content-addressable-store/</guid><description>Identify every object by its SHA-256 content hash — server-side dedup, verify-on-read, and a path that later mounted a filesystem. Teaches: content addressing principles, single write chokepoint, Bolt/Sentinel patterns.</description></item></channel></rss>