Glossary

Distributed file system

A distributed file system spreads files across many servers but presents them to applications as one ordinary file system with folders, paths and locks. Capacity and throughput grow by adding servers. The part that limits it is rarely disk speed. It is the metadata that tracks every name and location.

What gets distributed, and what limits it?

A single file server runs out of room, and its owner then faces a choice between buying a second server with a second folder tree or spreading one tree across many machines. A distributed file system takes the second path, and three separate jobs are spread out.

  • Data: files are split into chunks and protected by replication or erasure coding, with chunks placed on different servers.
  • Metadata: names, directories, permissions, timestamps and the map of where every chunk lives.
  • Coordination: locks, so two clients writing the same file do not overwrite each other.

Clients connect with the usual Linux or Windows file-sharing protocols, or through a native client that talks to the servers directly. Applications see a folder tree and need no changes.

Why does metadata break first?

Teams usually size a file system on throughput: how many gigabytes per second the servers can move. Real workloads hurt in a different place. Millions of small files, deep directory trees and directory listings generate huge numbers of metadata operations while moving very little data. Those operations hit the metadata service long before the disks run short of bandwidth, and a system that streams large files happily can stall on a build farm or a mailbox archive.

The useful question for any design is how metadata scales: held on one server, spread over a cluster, or fully distributed with no central point. That answer predicts behaviour at hundreds of millions of files better than any bandwidth figure.

How it differs from NAS and from object storage

A traditional filer is a pair of controllers in front of shelves of drives, so its ceiling is the controllers. A distributed file system is the scale-out answer to the same job, and teams moving from a crowded filer estate often land here, as in NAS consolidation.

Object storage avoids the metadata problem by dropping the folder tree: objects sit in flat buckets and are found by key. That is simpler and scales further, but applications can only replace whole objects. A distributed file system is the right shape when programs modify files in place or depend on locking. For write-once data such as backups and archives, a flat object pool is usually simpler to run.

Failure behaviour is the last thing worth testing. When a node drops out, data is rebuilt from the surviving chunks, and the metadata service has to stay available while it happens. A design whose metadata lives in one place turns a single server fault into a cluster-wide pause, which no amount of data protection fixes.

Frequently asked questions

Is a distributed file system the same as a clustered file system?

The terms overlap. Clustered file systems usually share one set of disks between a few servers. Distributed ones place data on each server's own drives, and scale to many more nodes.

How many files can one hold?

Designs advertise billions. The practical number depends on how the metadata is stored and how much of it fits in memory on the servers that serve it.

Does it need special client software?

Not always. Many expose standard file-sharing protocols. A native client usually adds throughput by talking to many servers in parallel.