How MooseFS is put together
A MooseFS cluster is a set of cooperating services running on commodity x86-64 and ARM servers. Together they present one storage pool with a single namespace: mount it as an ordinary POSIX file system, use it as a block device, or access it directly from your applications via the C API. The storage layer underneath stays online through failures, scales horizontally, and rebalances itself as you add or retire hardware.
Metadata on one path, data on another
Every MooseFS cluster — Community or Pro — is built around one idea: keep the file system’s bookkeeping separate from the data itself.
- Master Servers hold the metadata: the directory tree, names and permissions, and the map of which chunk of which file lives on which node. When an application opens a file, the client asks the Master where the data is — and from that moment on it talks to the storage nodes directly.
- Chunkservers store the data, split into chunks and spread across the cluster. Reads and writes run in parallel against many Chunkservers at once, and they replicate chunks between themselves to keep every file at its configured redundancy.
- Clients mount the cluster on Linux, FreeBSD and macOS; the Pro edition adds a native Windows client. Whichever way the data is accessed — mount, block device, or C API — it is the same namespace and the same chunks underneath.
File data never flows through a Master Server. That is why MooseFS has no central bottleneck: every Chunkserver you add brings more capacity and more bandwidth at the same time.
Two ways to protect the data
How well a file is protected is a policy, set per file or per directory — not a property of the whole cluster:
- Replication — a redundancy level tells MooseFS how many copies to keep, always on different Chunkservers. Lose a disk or a node, and the cluster heals itself: the missing copies are recreated automatically from the surviving ones.
- Erasure coding — space-efficient protection for large data sets: chunks are cut into parts and protected with parity sums. The Community edition supports a single parity part (4+1 or 8+1); Pro raises that to as many as nine (4+n, 8+n).
The full architecture, open source
A Community cluster runs a single active Master Server. Its metadata is still never trusted to one machine: Metaloggers keep continuously updated copies on separate hardware. If the Master’s server is lost, an operator brings the cluster back from a Metalogger’s copy — a manual step, with the data sitting safely on the Chunkservers the whole time. Everything else works exactly as described above: parallel I/O, replication, single-parity erasure coding. Free and open source under GPLv2.
The same architecture, with no manual steps left
A Pro cluster runs several Master Servers side by side — a leader and continuously synchronized followers. When the leader fails, a follower takes over automatically — no single point of failure, no restore step, no operator in the loop — and the cluster keeps serving. Pro also extends the storage layer itself: erasure coding with up to nine parity sums, and multi-location clusters that group Chunkservers by site, with per-location storage policies that keep data close to where it is used. With the native Windows client and 24/7 support from the engineers who write the code, Pro is the edition for production that cannot pause.
One codebase, two editions
Both editions share the same core code — the same on-disk format, the same file system semantics, the same tools. Migration between editions needs no re-platforming and no data conversion: the architecture you evaluate on Community is the architecture you run on Pro.
Component-level documentation
This page is a short overview. For component-level detail, configuration, and operational guides, see the Design & Architecture chapter in the documentation.