Email
The fastest way to reach us. We read every message and reply from a real engineer, usually within one or two working days.
Get help
Support, straight from the engineers
MooseFS is built and supported by Saglabs SA in Warsaw. For Pro deployments we offer 24/7 commercial support — dedicated advisors, remote and on-site assistance, proactive monitoring, and dedicated software releases. For everyone else, the same engineers who write the code read every email that comes in.
Below: how to reach us directly, where the community gathers, and the operational best practices we recommend for every production cluster.
Support channels
Talk to us directly
Phone
Office hours, Central European Time. Email first if your issue isn’t time-critical — written context helps us help you faster.
Professional & on-site
Pro customers get 24/7 commercial support with dedicated advisors, remote and on-site assistance, proactive monitoring, and dedicated releases. Tell us about your environment and we’ll come back with sizing and pricing.
Support request
Open a support request
For existing Pro customers: file a ticket and it lands straight in our helpdesk. Use the email tied to your contract or licence so we can match your account. Required fields are marked with.
Not a customer yet, or have a general product question? Use the product enquiry form instead.
Your support request is in
We’ve opened a ticket and the support team will follow up by email.
Community
Community resources
Two public channels we monitor. Useful for questions where a search-friendly, archived answer helps the next person too.
Stack Overflow
Ask under the moosefs tag. Good for usage questions, configuration help, and POSIX semantics — anything where a public, searchable answer is valuable.
GitHub issues
For suspected bugs and feature requests. Please include the MooseFS version, your OS, a short description of the cluster, and the reproduction steps.
Best practices
What we recommend for production
Ten operational recommendations the support team applies to every Pro deployment. Most apply equally to Community clusters — following them up front prevents the most common late-night surprises.
-
Set the replication goal to at least 2
The goal is the number of copies MooseFS keeps of each file’s chunks across chunkservers. It is the most important knob for keeping data safe. For clusters of 1 PiB or larger, raise the goal to 3 so a single concurrent failure never reduces a file to a single surviving copy.
-
Leave enough room for metadata dumps
The master server periodically dumps metadata to disk. Plan storage at
/var/lib/mfsusingRAM × (BACK_META_KEEP_PREVIOUS + 2) + (BACK_LOGS + 1) GiB. As a rule of thumb, a master with 128 GiB of RAM needs at least 435 GiB reserved for metadata. -
Put metadata on RAID 1 or RAID 1+0 — locally
Use a dedicated, mirrored array for
/var/lib/mfs. Never place master metadata on network-attached storage — the master needs predictable, low-latency local writes. -
Avoid virtual machines for performance-critical roles
VMs are fine for testing, but we don’t recommend them for high-performance production roles — especially master servers. Run the master on bare metal whenever possible.
-
JBOD and XFS for chunkservers
Give MooseFS the disks directly — one filesystem per disk, formatted XFS, no RAID underneath. MooseFS detects and isolates a failing disk; a RAID array hides corruption from it and masks the very signal you want to see.
-
Network: 1 Gbps minimum, 10 Gbps recommended
MooseFS is a network file system — the cluster is only as fast as its slowest hop. We recommend at least 1 Gbps between every node, and 10 Gbps for production. Use LACP between switches so a single link or switch failure doesn’t cut the cluster in half.
-
Enable memory overcommit on the master
Set
vm.overcommit_memory = 1on master servers. The master forks to dump metadata in the background; without overcommit the fork can be refused even when there is plenty of free RAM. -
Exclude MooseFS mounts from
updatedbThe
locateindexer walks every mounted filesystem by default, which generates pointless metadata traffic against the cluster. Addfuse.mfsto thePRUNEFSlist in/etc/updatedb.confon all clients. -
Keep operating systems current
MooseFS runs on Linux, FreeBSD, and macOS. Staying on a supported OS release keeps you on a supported kernel and a supported FUSE — both directly affect performance and reliability.
-
Right-size the cluster for HA
For MooseFS Pro with high availability, the minimum supported topology is 2 master servers and 3 chunkservers. Anything smaller works but cannot tolerate the failures it was deployed to survive.
Hardware & network
Hardware & network recommendations
A few more details on the hardware shape that works best in practice. None of this is a hard requirement — MooseFS will run on what you give it — but matching these guidelines tends to remove the most common bottlenecks.
Master server CPU
The master is a single-threaded process, so single-thread performance is the metric that matters — not core count. Pick a modern CPU with a high base clock (we’ve had good results with parts in the 3.6–3.9 GHz range, e.g. recent Xeon E-class chips). Disable hyper-threading on master servers.
Chunkserver CPU
Chunkservers benefit from multi-core CPUs — they serve many parallel client requests at once and do erasure-coding parity work. There’s no need for the very highest clock speeds here; balanced server-class CPUs are a good fit.
Network fabric
1 Gbps works for small or development clusters; 10 Gbps (or faster) is the right default for production. Bond uplinks with LACP across two switches so a single switch failure does not isolate any node.
Minimum HA topology
For MooseFS Pro with automatic failover: at least 2 master servers and 3 chunkservers. Smaller layouts will run, but cannot survive the failures HA is meant to absorb.
Documentation
Need the deep dive?
The full reference — installation, configuration, operations, and tuning — lives in the documentation. It is the source of truth for everything in this page and a great deal more.