A real kernel mount.
Flat memory at any scale.
mount -t seaweedvfs — a native Linux filesystem, not FUSE.
Cached reads and metadata never leave the kernel, and the client keeps no
per-file state: its memory is set by in-flight I/O, not by file count —
walking thirty-three million files leaves the daemon’s heap where it
started, while FUSE clients grow to gigabytes.
Every other client makes you choose
Distributed storage clients come in two shapes. FUSE mounts are easy to ship but bounce every operation through a userspace daemon that accumulates per-file state — we know, because our own FUSE mount hits multi-gigabyte memory at tens of millions of files. Kernel clients are fast but arrive with version matrices, dedicated cores, and remount-to-upgrade operations. seaweed-vfs is built to be both: kernel-fast, and as easy to run as a FUSE mount.
| Client | Architecture | The catch |
|---|---|---|
| FUSE clients (any) | A userspace daemon in the path of every VFS call | Up to 83% slower and 4× the latency in the USENIX FAST’17 study; daemon memory scales with tracked inodes — a 32M-inode FUSE mount can stall for half an hour on cache eviction |
| JuiceFS | FUSE, with a large I/O buffer and a 5M-inode default cache | Vendor guidance: total client memory ≈ 4× the buffer size, and shrink the inode cache to save RAM; their Kubernetes CSI budgets up to 5 GiB per mount pod |
| Mountpoint for S3 | FUSE, deliberately not POSIX | AWS’s own docs: no directory rename, no symlinks, no locks, no in-place edits — “don’t run vim in Mountpoint” |
| CephFS kernel client | In-kernel, features ride the kernel release train | Client caches pin metadata-server memory — “clients failing to respond to cache pressure” is a named cluster health warning, with MDS OOM as the failure mode |
| Lustre client | Kernel modules built against exact kernel versions | ~2 KB of client RAM per cached file; cloud vendors tell you to pin your kernel to a validated build; upgrading means unmount and module reload |
| WEKA client | Userspace DPDK daemon + kernel module | A dedicated physical core, 5 GiB minimum RAM, and 1.4 GiB of hugepages per frontend process — on every client node — plus client/backend version lockstep |
| GPFS / Storage Scale | Daemon + a “portability layer” rebuilt per kernel | ~10 KB of client RAM per cached file by IBM’s own sizing; a pinned pagepool at 10–25% of node RAM; rebuild the kernel layer on every kernel or Scale update |
| seaweed-vfs | Thin kernel module + stateless userspace daemon | Daemon memory never grows with file count — per-file caching lives in reclaimable kernel slab, and the heap is sized by in-flight I/O. Standard mount tooling, no reserved cores, and the daemon restarts under a live mount |
Competitor figures from each vendor’s own documentation and issue trackers, and the USENIX FAST’17 FUSE study. The 6.8 GB FUSE data point is our own Go mount at 33M files (seaweedfs#10020) — we hit FUSE’s ceiling ourselves, which is why the kernel mount exists. SeaweedFS figures measured on a 33M-file namespace walk, cgroup-attributed. Under sustained streaming the daemon holds transfer buffers too (~300 MB today) — bounded by I/O depth, not by how many files you store. Details in the kernel mount reference.
A thin module, a stateless daemon
A small C kernel module implements the filesystem; a Rust userspace daemon
(sw-kd) speaks to the SeaweedFS filer. The kernel calls the daemon
only on a cache miss or a write — everything warm is served in-kernel.
1. Kernel serves the hot path
Repeat reads, stats, and directory listings come straight from
the kernel’s page and dentry caches — with kernel readahead on
sequential reads, exactly like a local filesystem.
2. Daemon stays stateless
Inode numbers are derived (ino = hash(path)), so the daemon
keeps no inode or path map at all. Per-file caching lives in reclaimable kernel
slab the OS evicts under pressure — never in an unbounded userspace heap.
3. Standard tooling end to end
Installed by one command (DKMS builds for your kernel), managed with
mount, fstab, and systemd. An optional
io_uring fast path keeps many requests in flight.
The real page cache
Warm random reads are served from kernel memory without a userspace round trip — the structural payoff of being an actual filesystem, and the gap FUSE architecturally cannot close.
Upgrade under a live mount
The daemon restarts — and upgrades — without unmounting. No draining application nodes, no remount windows, no kernel rebuild ceremony for routine updates.
NFS re-export built in
Export a seaweedvfs mount with the standard kernel NFS server — rename-safe file handles included — so machines without the module reach the same namespace over NFSv4.
Behaves like a filesystem, because it is one
No custom mount helpers to learn, no sidecar orchestration. One installer
command, then the same mount, /etc/fstab, and
systemd workflow you use for every other filesystem — on any
Linux 6.1+ kernel, x86_64 or arm64.
- One-line install — auto-detects your package manager, architecture, and kernel; re-run it to upgrade in place
-
100% POSIX — hardlinks, permissions, atomic renames;
df,ls, and your tools just work - Fleet-ready — Secure Boot signing, pinned-kernel packages, and source builds for the environments that need them
More reasons teams pick SeaweedFS
Metadata at Scale
Sealed directories shrink the filer store 18–58× for cold trees — metadata becomes ordinary, erasure-coded volume data, still readable in place. See how →
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 →
Open Source vs Enterprise
Same cluster, same deployment, same APIs — see exactly what a license key adds, and what stays free. Compare editions →
Mount billions of files. Keep your RAM.
The kernel mount ships with SeaweedFS Enterprise — free for dev & test
under 25TB. Install it on one node and run find over your biggest
tree; watch the daemon not care.