MogileFS Explained: A Distributed File System for Redundant Object Storage

MogileFS is one of the original open-source answers to a problem every large web platform eventually hits: how do you store tens of millions of user files reliably and cheaply, without buying a SAN and without trusting any single disk? This guide explains what MogileFS is, exactly how its architecture works, how it compares to modern alternatives like Ceph and S3-compatible object stores, and how to size a real cluster on dedicated servers.

In one sentence: MogileFS is an open-source, application-level distributed file system that stores each file as multiple whole replicas spread across independent storage nodes, using a MySQL database to track where every copy lives — giving fault tolerance without RAID or shared storage.

MogileFS at a glance

The core idea: no RAID, no single point of failure

Traditional storage buys reliability with hardware — RAID arrays, dual controllers, expensive shared filers. MogileFS takes the opposite approach: assume the hardware is cheap and will fail, and get reliability from software instead. Every file is stored as one or more whole replicas spread across independent storage nodes. There is no striping and no parity to rebuild. If a disk dies, the copies on other nodes are still complete, and a background process simply re-replicates until the desired copy count is restored.

Because it operates at the application level rather than as a kernel filesystem, MogileFS is not mounted like NFS and does not provide POSIX semantics. Applications talk to it through a client library and address files by an opaque key, not by a path. That trade-off is exactly what lets it scale horizontally across ordinary disks on budget dedicated servers.

The four components

Because all shared state lives in MySQL, the trackers are stateless and interchangeable — you run several for high availability and any one can serve any request. The administrative CLI, mogadm, is used to register hosts, devices, domains and classes. The metadata database is the one component you must protect: put it on reliable storage and replicate it (typically MySQL primary/replica).

Domains, classes and replication

MogileFS organises files into domains (namespaces, e.g. one per application) and classes within a domain. A class carries a replication policy — most importantly its mindevcount, the minimum number of separate devices a file in that class must be copied to. A background replicator constantly compares reality against the metadata and makes or moves copies until every file satisfies its class policy. That same mechanism is how the cluster self-heals after a node or disk failure.

The durability target has a direct cost: a class with mindevcount=3 multiplies the raw capacity you must provision by three. That single number is the biggest driver of how much disk your cluster needs — plan it before you buy nodes.

How a file is written

1. The client asks a tracker to create a new file in a given domain/class.
2. The tracker picks suitable devices and returns temporary write URLs.
3. The client PUTs the data directly to one or more storage nodes over HTTP.
4. The client tells the tracker the write is done; the tracker records the file's location and key in MySQL.
5. Asynchronously, the replicator ensures the file reaches its full class replica count across separate devices.

“MogileFS is our open source distributed filesystem. Its properties and features include: application level — no special kernel modules required; no single point of failure; automatic file replication; better than RAID; flat namespace.”

— Danga Interactive, the original MogileFS project description

MogileFS vs Ceph, GlusterFS and S3/MinIO

MogileFS predates most of today's distributed-storage stack and occupies a deliberately narrow niche. Here is how it lines up against the tools people most often compare it to:

If you need a mountable POSIX filesystem, low-latency random reads/writes, or a standard S3 API, one of the others is the better modern choice. If you specifically want dead-simple, whole-replica blob storage that tolerates node loss without RAID and scales by adding cheap disks, MogileFS still does that job cleanly.

Where MogileFS fits — and where it doesn't

Great fit: user uploads, image galleries, email attachments, static assets — anything addressed by an ID and served back over HTTP, written once and read many times. Its strengths are cheap horizontal scaling, node-failure tolerance without RAID, and operational simplicity for that workload.

Poor fit: a mountable POSIX filesystem, low-latency random reads/writes, frequent in-place modification, or strong transactional semantics. Reach for CephFS, GlusterFS or an S3-compatible store instead.

Running MogileFS on dedicated servers

A minimal production deployment wants at least two storage nodes on separate physical machines (so a class with two replicas survives a full host loss), plus two trackers and a replicated MySQL pair for the metadata. Each storage node is just cheap disks and a running mogstored; you scale by adding more. This is exactly the workload that suits multiple independent dedicated servers in separate failure domains rather than one large box — you want raw disk and network isolation, not a shared chassis.

For the storage tier, capacity-per-dollar matters more than raw speed, so high-capacity HDD dedicated servers or dedicated storage servers are the natural home for replicas. Put the MySQL metadata node and the trackers on faster NVMe dedicated servers, and if replicas span multiple sites, provision 10 Gbps dedicated servers so re-replication after a failure doesn't saturate your links. Here are current dedicated servers you could build storage nodes on:

Suggested node sizing

Frequently asked questions

Is MogileFS still maintained and used in 2025?

MogileFS is mature and stable rather than actively evolving. It remains a solid, battle-tested option for its niche — high-volume blob storage on commodity hardware — even though newer object stores and clustered filesystems have taken over most general-purpose distributed-storage use cases.

Does MogileFS use RAID?

No. MogileFS deliberately avoids RAID and instead keeps multiple whole copies of each file on separate devices and hosts. The project historically described this as “better than RAID,” because a lost disk or node is repaired by re-replicating from surviving copies rather than rebuilding an array.

Can I mount MogileFS like a normal filesystem?

Not in the usual sense. It is an application-level store accessed by key through a client library or over HTTP; it does not provide POSIX semantics or a kernel mount. If you need a mountable filesystem, use GlusterFS or CephFS.

What database does MogileFS require?

A MySQL database holds all metadata — which files exist and on which devices their replicas live. The trackers are stateless; the MySQL instance is the component you must back up and make highly available.

How many servers do I need to start?

For real redundancy, at least two storage nodes on separate physical hosts, plus at least one tracker and one MySQL instance (two of each for high availability). Two independent dedicated servers are enough to survive a full host failure with a two-replica class.

Historical note and references

MogileFS came out of the mid-2000s LiveJournal engineering stack and, alongside memcached, Perlbal and Gearman, became a well-known building block for scaling large web properties on commodity hardware. It remains a dependable choice for its niche today. Primary sources worth reading: the MogileFS project page and code (originally at danga.com/mogilefs and now on GitHub), the Perl client on MetaCPAN, and the broader Danga Interactive architecture writeups from the LiveJournal era.