The Google File System

(GFS)
 Introduction
• Special Assumptions
• Consistency Model
• System Design
• System Interactions
• Fault Tolerance
• (Results)
 Assumptions
• The system will always be broken
• Files are BIG
• Large streaming reads / small random
reads
• Large sequential writes (appends)
• Lots of multiple appends
• High sustained bandwidth
 Consistency Model
• Consistent: All readers see same thing.
• Defined: You see exactly what you
write.
• Undefined: Consistent, but might not be
exactly as expected.
 How do Apps Deal?
• Parts of files are inconsistent
• Must do some checking of data:
– Application level checksums
 Single Master Architecture
• Good:
– Has global knowledge
• Can make intelligent placement/replication
decisions.
• Bad:
– Becomes a bottleneck
• Must limit it’s involvement in read/write
 Architecture
• Master
– Keeps track of everything

• Chunk Servers
– Where the data lives
– Each chunk is 64MB
• On other file systems ~8KB
 Let The Master Rule
• Namespace Locking
• Replica placement
• Creation
• (Garbage Collection)
 Metadata
• In Memory
– Fast
– Limited space
• Chunk Locations
– No persistent record
• Op Log
– Every change to metadata
 System Interactions
• To write:
– Ask master for chunk locations (cache)
– Push data to all chunks (to a buffer)
– Send write request to primary
– Primary writes changes (in order received)
– Primary forwards to secondaries (in order
received)
– Secondaries write changes, confirm.
 Record Append
• Atomic
• Allows for multiple writers
• May cause inconsistent states between
successful appends.
 Fault Tolerance
• Restore state fast
• Copies, Copies, Copies
• Checksums for data integrity
 Results summary
• When you build a file system around the
specific applications which use the
system, it works well.