Architecture

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.

This page is a short overview. For component-level detail, configuration, and operational guides, see the Design & Architecture chapter in the documentation.

Roles

The four roles in a cluster

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.

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 — metadata is never trusted to a single machine.

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.

Durability

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.

Deep dive

Component-level documentation

The marketing site keeps the architecture overview short on purpose. For chunk layout, master failover, metalogger promotion, network topology, and tunables, the documentation is the source of truth.

Read the Design & Architecture chapter    See features