.spec · comparison
Comparison with
extant formats.
How LimniFS differs from what already exists, and precisely which ideas are taken from where. Two axes matter: (1) LimniFS is an image-format VFS — images live on filesystems/object stores, not on block devices; (2) LimniFS treats compression, encryption, redundancy, and distribution as representations over a content-addressed identity plane, not as baked-in layout.
Classification
mutable, on block device immutable image, on any byte store
────────────────────────── ──────────────────────────────────
local ext4, XFS, APFS, ZFS, btrfs SquashFS, EROFS, DwarFS, LimniFS
distributed Ceph, GlusterFS, Taobao TFS* OCI layers, IPFS/UnixFS, casync
composefs (hybrid: EROFS + CAS store)
* Taobao TFS is a distributed service with its own block layer — included
because its slab-packing idea is adopted, but it is not an image format.LimniFS competes in the bottom-right quadrant and borrows selectively from the others. It is not a POSIX read-write filesystem, not a block allocator, not a cluster service.
Feature matrix
| dedup | per-class compression | staged compression | deltas / overlays | AEAD crypto | signatures | erasure coding | streaming / HTTP | spec indep. of impl | license | |
|---|---|---|---|---|---|---|---|---|---|---|
| LimniFS | ✓ BLAKE3(pt) | ✓ registry | ✓ tiers | ✓ 3 merge tiers | ✓ registry | ✓ sigstore | ✓ per-slab RS | ✓ locator reg. | ✓ spec-first | Apache/MIT |
| DwarFS | ✓ | ✓ categories | ✗ build-time | ✗ history | ✗ | ✗ | ✗ | ✗ | ✗ impl-is-spec | GPL-3 |
| SquashFS | ✗ | ✗ one codec | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ~ kernel docs | tools GPL |
| EROFS | ✗ | ~ per-file | ✗ | ✗ | ✗ | ~ fs-verity | ✗ | ✗ | ~ kernel UAPI | GPL-2 |
| composefs | ✓ CAS | ✗ | ✗ | ✗ overlayfs | ✗ | ~ fs-verity | ✗ | ~ ostree | GPL-2 | |
| OCI layers | layer-level | ✗ tar+gzip | ✗ | ~ ordered | ✗ | ~ cosign | ✗ | ✓ registry | ✓ spec | Apache |
| casync | ✓ chunks | ✗ one codec | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ HTTP | ~ blog+impl | LGPL |
| borg/restic | ✓ | ✗ | ✗ | ~ snapshots | ✓ | ✗ | ✗ | ~ repo proto | BSD/GPL | |
| git | ✓ | ✗ zlib | ✗ | ✓ packs/deltas | ✗ | commit sigs | ✗ | ✓ smart HTTP | ✓ docs+impl | GPL-2 |
| IPFS/UnixFS | ✓ per-block | ✗ | ✗ | ~ DAG | ✗ | ✗ | ✗ replication | ✓ gateways | ✓ spec | Apache/MIT |
| Taobao TFS | n/a service | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ replication | ✓ | ✗ | GPL-2 |
| ZFS/btrfs | ✓ (ZFS) | ✗ one codec | ✗ | snapshots | ~ ZFS native | ✗ | ✓ raidz | ✗ | ✗ | CDDL/GPL |
System-by-system: what we take, what we reject
DwarFS / dwarfs-t (closest relative)
Take: per-class compression via heuristics, fragment packing, strong dedup, fast random access. Reject: build-time-only compression decisions (LimniFS deepens in the background); implementation-as-spec monolith (LimniFS is spec-first with two readers); GPL-3; no crypto/signatures; no deltas or locators. dwarfs-t already proved the C++ stack can be modernized (folly/thrift removal) — LimniFS carries that instinct into a Rust rewrite with a stable format boundary.
SquashFS
Take: simplicity, ubiquity, kernel mountability. Reject: one codec per image, no dedup, no distribution story. SquashFS is the baseline LimniFS must beat on ratio (trivial) and on mount convenience (the FUSE + composefs paths exist for this).
EROFS
Take: kernel-native read performance, per-file compression choice. Reject: kernel-coupled metadata evolution, no identity plane (fs-verity is external), no crypto/deltas. LimniFS’s composefs-style path borrows EROFS as a component rather than competing with it.
composefs
Take: the split of metadata (EROFS) from a content-addressed object store; kernel-verified mounting. Reject: no compression pipeline of its own, no delta semantics, no crypto in the store, Linux-only. LimniFS generalizes the same idea to be locator-agnostic and distribution-native.
OCI images
Take: registry UX, content-addressed blobs, cosign-style signing (sigstore). Reject: tar-layer granularity (ordered, poor dedup, whole-layer pull for one file). LimniFS deltas + range streaming are the direct answer to OCI’s two worst properties.
casync
Take: chunk store + index separation, HTTP chunk serving. Reject: single codec, no fs-metadata sophistication, no crypto. LimniFS’s slab index is casync’s .caibx idea with an identity plane and a real VFS on top.
borg / restic
Take: authenticated encryption done right (they are the proof the audience wants it). Reject: backup-repo semantics (mutable stores, lock files), not mountable-first, no staged compression.
git
Take: delta chains, DAG versioning, content addressing as identity. Reject: per-object granularity at storage, zlib-only, no range streaming.
IPFS / UnixFS
Take: multihash identity (LimniFS DropIds are multihash-compatible), CAR transport, DAG pinning. Reject: per-block object overhead (LimniFS batches into slabs — the Taobao TFS lesson applied to IPFS-scale distribution).
Taobao TFS
Take: slab packing of small files into large objects with two-level addressing — the single most important storage-layout idea outside DwarFS. Reject: master-server service architecture; LimniFS is a format, not a cluster.
ZFS / btrfs (contrast class)
Take: checksumming everything, snapshots as first-class derivations (LimniFS deltas are the immutable-image analog). Reject: block-device coupling, mutable-state complexity — LimniFS deliberately has no volume layer.
Research formats
Academic and experimental formats investigated during the LimniFS wire-format research (2024–2026):
Content-Defined Merkle Trees (CDMT)
Nakamura et al. 2021. Combines content-defined chunking with Merkle trees for efficient, deduplication-friendly container delivery. Solves the chunk-shift problem; 40% network savings vs. conventional Merkle trees. LimniFS takes: the principle that chunk-stable Merkle boundaries compose with delta chains. Applied as: deterministic Merkle B-tree for the directory (per pivot decision D2).
Prolly Trees (Dolt)
Probabilistic B-trees built by recursively applying content-defined chunking. Production at Dolt (SQL database with Git-like versioning). LimniFS takes: content-addressed structural sharing, multihash-compatible node hashes. Differs: LimniFS uses deterministic splits (not probabilistic CDC) for §1.4 determinism compliance.
SolFS (USENIX ATC ’25)
Operation-log versioning filesystem for mobile cloud backup. Hash-free dedup. LimniFS takes: validates that “replay until squeezed” (overlay → flatten → turnover) is a viable production model. Differs: LimniFS uses hash-based identity (required for distribution); SolFS avoids hashing for mobile CPU efficiency.
HydraFS (FAST ’10)
High-throughput CAS filesystem for the HYDRAstor content-addressable storage system. LimniFS takes: CAS as a first-class paradigm; two-level addressing (slice → drop → slab extent). Differs: HydraFS is a service with its own block layer; LimniFS is an image format.
Lite2 / Lite3 (2024–2025)
Schemaless zero-copy serialization format. LimniFS takes: validates schemaless + zero-copy as a viable combination. Differs: LimniFS is schema-driven (spec-first) with byte-addressability — the spec IS the schema.
The five differentiators (why LimniFS exists at all)
- Identity/representation partition. No extant image format separates “what the bytes are” from “how they are stored” this strictly. It is what makes every other differentiator composable.
- Staged compression. DwarFS-class ratios with tar-class write latency. Nobody else re-compresses in the background while keeping identity stable.
- Metadata-only flatten. Folding a delta chain costs O(metadata) with zero data movement. OCI, git, and DwarFS all move bytes to merge.
- Crypto/redundancy/DMS in the format. AEAD registry, per-recipient HPKE, per-slab RS, dead man’s switch — as registry-gated representations, not bolt-ons. borg/restic prove demand; no mountable image format has it.
- Locator-agnostic distribution. The same image mounts from a file, an HTTP static host, S3, or IPFS with mirror racing — streaming-native, no full download, lying mirrors detected by construction.
Honest weaknesses (what others do better)
- Kernel-native random read: EROFS beats any FUSE path; our composefs path closes most of the gap on Linux only.
- Ecosystem/tooling: SquashFS and OCI are everywhere; LimniFS starts with one CLI and one consumer (tebako).
- Mutable workloads: anyone needing read-write needs ZFS/btrfs/ext4, full stop. LimniFS will never serve them — that is positioning, not a bug.
- Maturity of threat model: borg/restic have years of adversarial review; LimniFS’s crypto is new and must earn trust via the conformance/fuzz program and external audit before Phase 2 ships encrypted images broadly.