The encyclopedia · Engineering & Operations · Technical decision · 2003–2010
Google's File System treated crashing disks as normal and scaled on cheap machines
GFS split files into 64MB chunks, kept three replicas per chunk and made appends atomic — hundreds of terabytes on commodity servers.
The solution
Google's crawlers and indexers produced data that outpaced what a single reliable server could store, and the hardware fleet failed constantly. Earlier distributed file systems assumed components mostly worked; GFS assumed they would not.
The 2003 SOSP paper describes GFS: files split into 64MB chunks, each chunk replicated on three chunkservers, with one master handling metadata, leases and garbage collection while clients move data directly. Since appends, not rewrites, dominated, record append was made atomic so many producers could write one file without locks.
The largest cluster at the time stored hundreds of terabytes across thousands of disks on over a thousand machines, serving hundreds of clients. GFS became the storage layer under MapReduce and Bigtable, and its design was reimplemented as HDFS in the open-source Hadoop stack.
Why it worked
- Three-way replication turns disk loss into a routine repair event.
- A single master simplifies placement, leases and garbage collection.
- 64MB chunks amortize network overhead and shrink metadata.
- Atomic appends let thousands of producers share a file without locking.
What can be applied
If hardware fails constantly, stop buying reliable hardware: design so replication and retry are the normal path, and make the common write (appends) atomic instead of making every operation robust.
Aftermath
GFS ran Google's data pipelines for years and inspired HDFS, the storage layer of the Hadoop ecosystem that powered the first decade of big data outside Google. Its architecture remains the template for replicated, append-heavy storage systems; Google later evolved it into Colossus with distributed metadata.
Sources
spotted an error? The archive wants to know.