By 2002, Google was storing and processing more data than almost anyone else on the planet, on hardware that was, by design, cheap and unreliable. Buying fewer, more reliable machines was not the plan. The plan was to accept that disks and machines fail constantly at that scale, and build a filesystem that treats failure as a Tuesday, not an emergency.
Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung's answer, the Google File System, is unapologetically specialized. It is not a general-purpose filesystem, and the paper says so directly: it was co-designed alongside the applications that would run on it, most notably MapReduce, and it makes deliberate trade-offs a POSIX filesystem never would.
GFS splits huge files into large 64MB chunks, replicates each chunk three times across cheap commodity machines, and uses a single master to track only metadata, never the data itself. Component failure is treated as constant and routine, not exceptional, and the whole design is tuned for huge files, sequential reads, and appends rather than small random writes.
Designed for a specific workload, on purpose
Most filesystem papers try to be general. GFS starts from the opposite instinct: name the actual workload precisely, and build only for that.
Failures are the norm. With thousands of commodity machines, some component is always broken. The system has to detect, tolerate, and recover from failures as routine operation, not as rare edge cases requiring a human.
Files are huge. Multi-gigabyte files are common; a design tuned for millions of tiny files would waste effort GFS does not need to spend.
Reads are mostly large and sequential, or small and random, and writes are overwhelmingly appends, not modifications of existing bytes. Think of a crawler appending new documents, or a MapReduce job appending output records, not a database updating a row in place.
High sustained throughput matters more than low latency for most of the applications GFS was built for. A batch analytics job cares about total time to process a terabyte, not the latency of any single read.
Every unusual design decision later in this paper traces back to one of these four assumptions. If you ever wonder "why would they build it that way," the answer is almost always "because that is exactly what a MapReduce-style workload needs, and nothing more."
One master, many chunkservers, and a strict division of labor
A GFS cluster has a single master and many chunkservers. Every file is split into fixed-size 64MB chunks, each replicated on multiple chunkservers, three copies by default. The master stores only metadata: the filesystem namespace, which chunks make up which file, and which chunkservers currently hold each chunk. It never sees the actual file contents pass through it.
A client asks the master once for chunk locations, then talks directly to a chunkserver for the actual data transfer. The master is on the control path, never on the data path.
This split is the single most important architectural decision in the paper. Keeping bulk data off the master means the master's job is cheap enough to do from an in-memory data structure, and a single master, despite sounding like an obvious bottleneck and single point of failure, turns out to be a perfectly reasonable design as long as it never has to move the data itself.
Why 64MB, specifically
A large chunk size is a deliberate trade-off. It means a client that wants to read a large file needs far fewer round trips to the master to discover chunk locations, one lookup can cover a big chunk of the file. It also means the master's metadata, which lives entirely in memory for speed, stays small even for filesystems holding petabytes: a 64MB chunk size means roughly 64,000 times fewer metadata entries than a 1KB chunk size would produce.
The downside is real and the paper is upfront about it: a file made of very few chunks (a small file, or even a single-chunk file) can create a hot spot if many clients read it at once, since only a few chunkservers hold that chunk. Their practical fix at the time was simply to allow higher replication factors for known hot files.
Writes go through a leased primary, to keep replicas in the same order
Reads are simple: ask the master, then read from any replica. Writes need every replica to apply mutations in the exact same order, or replicas would diverge. GFS solves this with a lease: the master grants one replica the role of primary for a chunk, for a limited time (60 seconds, renewable), and only that primary decides the serial order of writes to it.
The clever part is separating data flow from control flow. The client pushes the actual bytes to be written along a chain of chunkservers, each one forwarding to the next closest one on the network, rather than the client uploading the same data three separate times to three separate machines. Only once every replica has buffered the data does the client ask the primary to actually apply the write, at which point the primary assigns a serial number and forwards the write order, not the data, to every secondary in parallel.
Data is pushed once, pipelined chunkserver to chunkserver along the fastest network path. Only the write order itself, a tiny message, is fanned out separately by the primary.
This is why GFS achieves high write throughput on commodity gigabit-era networks: the expensive part, moving the actual bytes, only ever travels each network link once, while the cheap part, agreeing on ordering, is a small, fast, separate exchange.
GFS also exposes a special record append operation, guaranteed to append data atomically at least once, at an offset GFS itself chooses, rather than one the client specifies. This maps perfectly onto MapReduce: many worker processes can append their output to the same shared file concurrently without any of them needing to coordinate who writes where.
Recovering from a master or chunkserver dying
The master keeps every metadata mutation in an operation log, replicated to multiple remote machines before a mutation is considered durable, plus periodic checkpoints so a restart does not need to replay the entire history from the beginning. Shadow masters read this replicated log to serve read-only metadata queries even if the primary master is temporarily unavailable, though only the one true master can grant leases or make mutations.
Chunkservers are simpler: the master polls every chunkserver with periodic heartbeats. A chunkserver that stops responding has its chunks marked under-replicated, and the master directs other chunkservers to re-replicate them elsewhere, the same self-healing instinct Dynamo and MapReduce both lean on. Each chunkserver also independently checksums every 64KB block of every chunk it stores, since disks silently corrupt data far more often than most engineers assume, and checks a block's checksum on every read before serving it.
Why this paper still matters
GFS was never released outside Google, but the architecture became a template. Apache Hadoop's HDFS is close enough to a direct clone that its NameNode and DataNode map almost one-to-one onto GFS's master and chunkservers, and an entire generation of engineers learned distributed storage through HDFS's documentation before ever reading this paper. Google itself eventually replaced GFS internally with Colossus, built specifically to remove the single master's metadata ceiling that GFS accepted as a reasonable trade-off in 2003.
Read together with MapReduce, which this site also covers, the two papers form a matched pair: GFS gives MapReduce data locality to schedule against and a place to durably write output, and MapReduce gives GFS its dominant workload, huge sequential reads and appends, that shaped every design choice in this paper. Neither paper fully makes sense in isolation from the other.
Key takeaways: a single master holding only metadata can scale surprisingly far as long as bulk data never flows through it, large 64MB chunks trade a small amount of internal fragmentation for far less metadata and far fewer master round trips, and separating data flow (pipelined, once) from control flow (a small serial-order message) is what makes replicated writes both consistent and fast.
