How MooseFS is put together
A MooseFS cluster is made of four cooperating roles running on commodity x86-64 servers. Together they present a single POSIX namespace that mounts like an ordinary file system — while the storage layer underneath stays online through failures, scales horizontally, and rebalances itself as you add or retire hardware.
The diagram above is the whole cluster in one picture. Redundant Master Servers coordinate everything and hold the file-system metadata; a Metalogger keeps an off-master copy of that metadata so it is never trusted to a single machine; Chunkservers hold the actual file data, split into chunks and spread across many nodes; and Clients mount the cluster and see it as one ordinary POSIX file system. Each role is a separate process — you can co-locate them on the same hardware for small clusters, or spread them across dedicated nodes as the deployment grows.
The four roles
- Master — Holds the file-system metadata — the directory tree, permissions, and the map of which chunks live where — and coordinates the cluster. In the Pro edition the Master runs with redundant copies so the cluster keeps serving through a Master failure.
- Chunkserver — Stores the user data itself, split into chunks and spread across many nodes. Reads and writes happen in parallel against multiple Chunkservers, so there is no central server or single network link to become the bottleneck.
- Metalogger — Keeps a continuously updated, off-master copy of the metadata. If the active Master is lost, a Metalogger’s copy is what the cluster is brought back from.
- Client — A native mount client for Linux, FreeBSD and macOS, plus a native Windows client. Applications mount MooseFS and use the standard file APIs — no SDK, no protocol change, no rewrites.
Redundant metadata, redundant data
Reliability in MooseFS is layered. Metadata is kept in two or more copies on physical, redundant servers, so a single machine failure cannot lose the directory tree. User data is redundantly spread across the storage nodes, with two ways to protect it:
- Replication (goal-based) — Set a copy goal per file or per directory and MooseFS keeps that many copies on different Chunkservers, rebalancing automatically when nodes are added, lost, or replaced.
- Erasure coding — Space-efficient durability via error-correction codes. The Community edition supports erasure coding with a single parity part; the Pro edition supports erasure coding with up to 9 parity sums for stronger guarantees at the same raw cost.
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.