Frequently asked questions
A curated set of the questions we hear most often from people evaluating MooseFS or planning their first production deployment. We’ve kept the answers short and pointed at the documentation whenever the full answer benefits from more depth. If your question isn’t here, the support team is one email away.
General Editions & licensing Deployment & hardware Operations & data Support
About MooseFS
What MooseFS is, what it isn’t, and where it sits among the other distributed file systems you may be evaluating.
What is MooseFS, in one paragraph?
MooseFS is a software-defined, POSIX-compliant distributed file system. It pools storage across commodity x86-64 servers into a single, fault-tolerant namespace that mounts on Linux, FreeBSD, macOS, and Windows. Data is spread across chunkservers, metadata lives on a master, and clients see one filesystem regardless of how many machines back it. See What is MooseFS for the longer version.
Is MooseFS 64-bit compatible?
Yes — MooseFS is built for 64-bit platforms.
What are the supported limits?
Maximum file size: 257 bytes (128 PiB). Maximum filesystem size: 264 bytes (16 EiB). Maximum number of files: 231 (~2.1 billion). In practice the cluster is bounded by your hardware budget long before any of these.
Does MooseFS support file locking?
Yes, since MooseFS 3.0. Both POSIX advisory locks (fcntl) and BSD-style locks (flock) are supported.
Does MooseFS support supplementary (secondary) groups?
Yes. Permission checks honour the full set of POSIX supplementary groups, not just the user’s primary group.
Can I keep source code, mailboxes, or many small files on MooseFS?
Yes. The chunk size is hard-coded to 64 MiB with 64 KiB blocks, so each small file occupies at least one block plus a small per-chunk checksum and header overhead. The space cost is real, but for almost every workload — source repos, mail servers, web assets, container images — it’s a non-issue in practice. For a mail server specifically: yes, MooseFS works, with the expected behavior that very high concurrent activity may slow individual operations under load.
Community vs Pro
MooseFS ships in two editions on a shared codebase. Pick the one that matches your environment and the support level you need.
What’s the difference between Community and Pro?
Community is open source under GPLv2 — free forever, single-master, and a good fit for development, smaller production deployments, and learning. Pro is the commercial edition, with automatic master failover, multi-master high availability, stronger erasure-coding profiles, a native Windows client, and 24/7 manufacturer support. The full feature-by-feature comparison lives on Pro vs Community.
What is the minimum number of chunkservers?
In the Community edition the minimum equals the highest replication goal configured in the cluster — goal 2 needs 2 chunkservers, goal 3 needs 3, and so on. In the Pro edition we require at least 3 chunkservers regardless of goal, because Pro’s HA topology is designed around tolerating a chunkserver failure without losing redundancy. For Pro HA itself we also recommend at least 2 master servers.
Where do I download MooseFS?
Community packages for every supported Linux distribution, FreeBSD, Raspbian, and macOS are on the Download page. The source tree lives at github.com/moosefs/moosefs. For Pro, request a quote and we’ll send your repository credentials with the offer.
Sizing, network, and disks
High-level guidance on what a healthy cluster looks like. The Get help page has the full ten-point best-practices checklist.
What resources does the master server need?
The master keeps the full filesystem structure in RAM, so RAM is the critical resource — sized by the number of files and directories, not by total bytes stored. Single-thread CPU performance matters more than core count (the master is a single-threaded process). Plan local, low-latency disk for the periodic metadata dump — never network-attached storage for /var/lib/mfs. A 128 GiB master typically needs at least ~435 GiB of local disk reserved for metadata dumps and rotated change logs. Full guidance is on Get help.
How much CPU and RAM do chunkservers use?
Chunkservers are light on resources — typically 15–30% CPU and 100 MB to 1 GB of RAM under steady load. Usage scales with the number of operations and the file/folder count, not with raw stored bytes. Multi-core CPUs help (chunkservers serve many parallel client requests and do parity work for erasure coding); peak clock speed matters less here than on the master.
What network do you recommend?
MooseFS is a network file system — the cluster is only as fast as its slowest hop. We recommend 1 Gbps minimum and 10 Gbps (or faster) for production. Use jumbo frames (MTU 9000) where the whole path supports it, and bond uplinks with LACP across two switches so a single switch failure doesn’t cut the cluster in half. For very large clusters with many chunkservers, optical or aggregated inter-switch links are worth the spend.
Should chunkserver disks use RAID?
No. Give MooseFS the disks directly — one filesystem per disk, formatted XFS, no RAID underneath. MooseFS detects a failing disk and re-replicates its chunks elsewhere; a RAID array hides the failing disk from MooseFS, which is the opposite of what you want. (Master metadata is the exception — that does belong on a local RAID 1 or RAID 1+0 mirror.)
Can I run MooseFS in virtual machines?
VMs are fine for testing and for non-critical roles. For performance-critical production — especially master servers — we recommend bare metal. The master’s single-threaded, latency-sensitive workload is the worst case for the indirection a hypervisor adds.
Can I add or remove chunkservers and disks while the cluster is online?
Yes. Adding a chunkserver or a disk is a hot operation — the new capacity joins the cluster, and MooseFS gradually rebalances chunks onto it (deliberately gradually, to avoid hurting foreground performance). Removing is staged: mark the disk or chunkserver for removal, MooseFS replicates its chunks to other nodes to maintain the goal, and once replication completes you can detach. The full procedure (including hot-swap variants) is in the documentation.
Performance and data behavior
What to expect once the cluster is running — performance, replication, and the small surprises about how disk usage is reported.
What read/write throughput should we expect?
Honest answer: it depends on your hardware, your network, the block size your applications use, and your access patterns. MooseFS’ design scales horizontally — throughput grows close to linearly with the number of chunkservers and network capacity for parallel-access workloads. We’re happy to talk through expected numbers for a specific deployment; tell us about your environment.
Does the replication goal affect performance?
Generally no. Higher goals can marginally help read performance when many clients pull the same file (more copies, more sources). Writes use chain replication, so write throughput is essentially independent of the goal value.
Are concurrent reads and writes supported?
Yes. All reads run in parallel. Writes also run in parallel, with the exception that two writes targeting the same chunk are serialised by the master to keep ordering well-defined.
Why does df -h report different values than expected?
Two reasons. First, each chunkserver reserves a small overhead (about 256 MB per partition) that the master subtracts from reported capacity. Second, if a chunkserver disk also stores non-MooseFS data, df on the client counts that too. For an accurate per-directory view of what MooseFS itself is using, run mfsdirinfo.
I deleted files but the reported size didn’t drop. Why?
MooseFS doesn’t erase files immediately on delete — they go to a trash area first, so you can undelete them. The retention period is configurable per directory tree. Once the period expires, the chunks are reclaimed in the background. Full answer in the docs →
What replication goal should I use?
At least 2 for any data you care about. For clusters of 1 PiB or larger, raise the goal to 3 so a single concurrent failure never leaves a file with only one surviving copy. The goal is configurable per directory tree, so you can spend bytes on the trees that warrant it. Erasure coding (Pro) is an alternative when raw storage cost matters more than write throughput.
Getting help
How do I get support?
For Community users: email contact@moosefs.com — the engineers who write MooseFS read every message — or use the public channels on Stack Overflow and GitHub issues. For Pro customers: 24/7 commercial support, dedicated advisors, remote and on-site assistance, proactive monitoring, and dedicated software releases. Full breakdown on Get help.
Which versions are currently supported?
The 4.x stream is the actively-supported release for both Community and Pro; the Pro 5.x stream opened in April 2026 alongside it. The full lifecycle — release dates, latest point releases, end-of-life dates — lives on Versions.
How do upgrades work?
MooseFS supports rolling upgrades — you can move from one major version to the next while the cluster keeps serving. The documentation has step-by-step instructions for each upgrade path: docs.moosefs.com/upgrade . If you’d like an engineer to look over the plan before you start, get in touch.