The Google File System

1. The Google File System (GFS)

2. Introduction • Special Assumptions • Consistency Model • System Design • System Interactions • Fault Tolerance • (Results)

3. 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

4. Consistency Model • Consistent: All readers see same thing. • Defined: You see exactly what you write. • Undefined: Consistent, but might not be exactly as expected.

5. How do Apps Deal? • Parts of files are inconsistent • Must do some checking of data: • Application level checksums

6. 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

7. Architecture • Master • Keeps track of everything • Chunk Servers • Where the data lives • Each chunk is 64MB • On other file systems ~8KB

8. Let The Master Rule • Namespace Locking • Replica placement • Creation • (Garbage Collection)

9. Metadata • In Memory • Fast • Limited space • Chunk Locations • No persistent record • Op Log • Every change to metadata

10. 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.

11. Record Append • Atomic • Allows for multiple writers • May cause inconsistent states between successful appends.

12. Fault Tolerance • Restore state fast • Copies, Copies, Copies • Checksums for data integrity

13. Results summary • When you build a file system around the specific applications which use the system, it works well.