Single master not a GFS bottleneck

GFS uses a single master to keep the design simple and to allow global decisions (chunk placement, replication). A single master could limit scalability, so GFS is designed to keep its involvement in each operation minimal.

Reasons it is not a bottleneck

1. Master is not in the data path: clients ask the master only for metadata (chunk handle and locations). The actual reading and writing of data happens directly between clients and chunkservers.
2. Large chunk size (64 MB): fewer chunks per file means fewer metadata requests to the master. A client reading a large file contacts the master once per 64 MB.
3. Client caching of metadata: the client caches chunk locations for some time, so repeated accesses to the same chunk do not contact the master again.
4. Batching: a client can ask for several chunks in one request, and the master can reply with information about the chunks that follow, at almost no extra cost.
5. All metadata is in memory: the master serves requests quickly, and scanning memory for garbage collection and re-replication is efficient. Metadata is small (under 64 bytes per chunk).
6. Light-weight operations: the master does not persist chunk locations; it learns them from chunkservers. Only namespace and mapping changes go to the operation log, which is checkpointed (compact B-tree-like form) to keep restart fast.
7. Leases: the master delegates control of each write to a primary chunkserver by a lease, so it does not coordinate every mutation.
8. Replicas and shadow masters: the operation log is replicated, and shadow masters provide read-only service, reducing load and failure risk.

Therefore a single master handles the metadata work of a cluster with thousands of chunkservers and hundreds of clients without becoming a performance limit.