Concepts
Single-master chunked storage
Intuition
Imagine a giant library with millions of books spread across several warehouses. Instead of asking each warehouse where a book is, you have a single central card catalog that knows exactly which warehouse (and which shelf) each book is stored on. You consult the catalog only to find out the address, and then go straight to the warehouse to get the book — the catalog never holds the book itself, it only points to where it is.
How it works
GFS organizes a cluster into a single master process and many chunkservers. Each file is divided into large fixed-size chunks (64 MB), and each chunk is replicated (by default on three chunkservers) and stored as an ordinary file on each one's local disk. The master is deliberately kept out of the data path: it stores only metadata — the namespace, the mapping from each file to its ordered list of chunks, and the current location of each chunk's replicas. A client that wants to read or write first asks the master which chunkservers hold the desired chunk, caches that answer for a while, and then talks directly to the chunkservers — the chunk's bytes never pass through the master. Choosing a large, fixed-size chunk is a deliberate trade-off: it keeps the per-chunk metadata small enough to fit in the master's memory even for huge files, and it lets a client perform several sequential operations on the same chunk with a single initial request to the master, which matches the sequential, append-dominated access pattern the system was built to support.
In practice
This master/worker pattern with large blocks of data became a recurring template in batch distributed storage: HDFS mirrors this separation directly in the NameNode/DataNode pair, explicitly inspired by GFS. You choose this design when you need to store huge files, written mostly by append and read sequentially by many machines in parallel, and when you can tolerate a single process centralizing metadata as long as it never becomes a bottleneck for the data traffic itself — Google itself later evolved to Colossus to remove the scalability ceiling of having only one master.
Use it in a design
Practice the cases that rely on this concept in the System Design school.