Billions of files.
A metadata store that stays small.
Every file system pays for metadata per file — in RAM, flash, or a replicated database — and cold files pay that price forever. SeaweedFS seals cold directories so their metadata becomes ordinary volume data: compressed, erasure-coded, even cloud-tiered, and still fully readable in place.
Cold files, hot metadata
In every distributed file system, each file costs a metadata record in the hottest, most expensive tier — and the bill never expires. A file written ten years ago costs as much to index as one written today. The industry’s answer is to keep all metadata on premium media — more RAM, more flash, more metadata servers. SeaweedFS asks a different question: why should cold metadata be resident at all?
| System | Where per-file metadata lives | What that means at a billion files |
|---|---|---|
| HDFS | NameNode JVM heap — roughly 150 bytes of RAM per file, directory, and block, forever | Heap and GC tuning, then federation to shard the namespace once one NameNode is not enough — and archive-tier files keep paying full price |
| CephFS | Metadata servers (MDS) caching dentries and inodes in RAM over a RADOS pool — roughly 1 GB of cache per 100k active inodes | MDS cache sizing, then multi-MDS — where the dynamic balancer ships disabled and the documented advice is pinning subtrees by hand |
| JuiceFS | An external metadata database — Redis holds about 300 bytes of RAM per file, or TiKV/SQL | 100M files ≈ 30 GiB of Redis RAM, with ~100M files as the vendor’s own ceiling; scaling out to TiKV multiplies metadata latency 3–7× |
| Lustre | Dedicated metadata servers with flash MDT targets — about 2 KB per inode on the MDT | A 256 GB-RAM MDS caches about 130M inodes — 13% of a billion-file namespace; scaling means more metadata hardware (DNE) |
| WEKA / VAST / Qumulo | Metadata distributed across NVMe or storage-class memory — every file, hot or cold, stays on flash permanently | It scales — on the most expensive tier in the system, priced accordingly. Cold files never stop paying flash prices |
| MinIO | No metadata store — metadata sits beside each object on disk | Nothing to outgrow, but no fast namespace either: listings walk the disks, with ~10,000 objects per prefix as the vendor’s guidance |
| SeaweedFS | Hot paths in the filer store — cold directories sealed into compressed chunks on ordinary volumes | Cold metadata is erasure-coded, cloud-tierable, and readable in place: 18–58× smaller, measured. Cost tracks your working set, not your history |
No other mainstream system ships transparent cold-metadata offload — the closest
prior art, Hadoop Archives, is an offline batch job that produces an immutable archive
behind a separate har:// scheme. Sealing is transparent, reversible, and
in-namespace. Vendor figures from public architecture documentation; SeaweedFS figures
measured on a live production store — methodology in the
sealed directories docs.
Seal a directory, keep everything readable
Sealing packs a cold directory’s entries into compressed segment chunks stored on volume servers, leaving only the directory entry and a small index in the filer store.
1. Pack
Child entries are serialized and zstd-compressed into segment chunks — ordinary volume data. Siblings share needles, so even 450,000 small directories seal in hundreds of uploads, not hundreds of thousands.
2. Index
The directory entry keeps a tiny sorted manifest — first name, last name, and chunk per segment. A million-entry directory needs about 12–24 KB of index, and point lookups fetch exactly one segment.
3. Purge
The per-file rows are deleted from the filer store. Listings stream segments in order; lookups binary-search the manifest. To readers — FUSE, S3, HDFS — a sealed directory is indistinguishable from a normal one.
Crash-safe end to end
An evented fence, a build journal, and replay-on-recovery mean a filer that dies mid-seal is finished or rolled back automatically — and the change converges across filer peers.
Reversible in one command
fs.unseal materializes the children back into the filer store exactly
as they were. Sealing is a physical layout change, never a logical one —
mirrors and backups are unaffected.
Metadata becomes data
Segment chunks are ordinary needles: they inherit erasure coding (1.2× overhead instead of 3× replicas), cloud tiering, replication, and vacuum — the cheapest storage in the cluster instead of the dearest.
Sealed doesn’t mean stuck
Seal frozen for finished data — fully read-only, and mount clients may cache its listing forever. Or seal mutable for data that is mostly settled: writes land as small overlay records next to the manifest, and a background compaction folds them back in once the directory goes quiet.
- Policy-driven — gitignore-style rules seal anything idle past a threshold, automatically
- Event-driven compaction — the worker watches the metadata event stream, so checking cost scales with writes, not with how much you’ve sealed
- Admin UI — rule editor, dry-run previews, sealed badges in the file browser, one-click mode flips
More reasons teams pick SeaweedFS
Point-in-Time Recovery
Roll a folder, bucket, or object back to any second in the retention window — overwrites and renames included, with a preview before anything changes. See how →
Kernel Mount
A native Linux mount — not FUSE — whose client memory stays flat as file counts grow, managed with standard mount and fstab tooling. Meet it →
Open Source vs Enterprise
Same cluster, same deployment, same APIs — see exactly what a license key adds, and what stays free. Compare editions →
Stop paying full price for cold metadata
Sealed directories ship with SeaweedFS Enterprise — free for dev & test under 25TB. Add a license key to the cluster you already run and seal your first archive this week.