GFS master role in read/write

Role of the GFS master

The master is the single metadata server and coordinator of the cluster. It does not carry file data, it only guides.

During read:

• Keeps the namespace and file-to-chunk mapping.
• Given file name and chunk index, returns the chunk handle and the locations of its replicas to the client.

During write / append:

• Decides which chunkserver holds the lease for the chunk and makes it the primary (lease normally 60 s, extendable).
• Returns the identity of the primary and secondary replicas to the client.
• Creates new chunks when needed, places replicas across racks and disks, and keeps chunk version numbers to detect stale replicas.

Other tasks: heartbeat monitoring, re-replication when replicas are lost, load balancing, garbage collection, and operation-log management.

Read flow

1. The client translates (file name, byte offset) into a chunk index using the fixed chunk size.
2. It sends (file name, chunk index) to the master.
3. The master replies with the chunk handle and replica locations; the client caches this.
4. The client sends the read request to the closest replica, which returns the data.

Write flow (control and data)

 Client                Master          Primary    Secondaries
   |-- 1 who holds lease? -->|             |           |
   |<-- 2 primary+replicas --|             |           |
   |-- 3 push data ------------------------>--------->  (data flow,
   |      (chained to all replicas, cached in buffers)    pipelined)
   |-- 4 write request ------------------>|           |
   |                        |      5 assign serial     |
   |                        |      number, apply       |
   |                        |             |-- 5 fwd -->|
   |                        |             |<-- 6 ack --|
   |<-- 7 reply (success or error) -------|           |

1. Client asks the master which chunkserver holds the lease and where the other replicas are.
2. The master replies with the primary and secondary replicas.
3. The client pushes data to all replicas; data flows along a chain from nearest to nearest (to use each machine's network bandwidth fully) and is held in a buffer (LRU) by each chunkserver.
4. After all replicas confirm receipt, the client sends the write request to the primary.
5. The primary assigns consecutive serial numbers to all mutations, applies them locally, and forwards the request to the secondaries, which apply them in the same order.
6. The secondaries reply to the primary when finished.
7. The primary replies to the client; any errors are reported and the client retries.

Control vs data flow

• Control messages (metadata requests, lease grants, write request/commit order) go between client, master and primary.
• Data goes directly from the client to chunkservers, and between chunkservers in a pipeline; it never passes through the master. This keeps the master from being a bottleneck.

Message summary

The data path is decoupled from the control path: data is pushed along a chain of chunkservers to use each machine's full outgoing bandwidth, while control follows a primary-secondary model that guarantees the same mutation order on all replicas.