Why it matters
Block placement determines three qualities operators care about: durability, read bandwidth, and write bandwidth. A cluster that survives rack failure needs replicas on multiple racks. A cluster that reads efficiently prefers replicas on the same rack as the reader. A cluster that writes efficiently minimizes cross-rack traffic during the write pipeline. These three goals conflict, and the HDFS default policy is the historically-proven compromise that gets most of the way on all three at once.
Beyond the default, tuning becomes important for storage-heavy clusters that use erasure coding for cold data, for latency-sensitive workloads that want replica affinity for particular applications, and for cloud deployments where zones replace racks and cost accounting turns cross-zone bandwidth into a first-class metric.
The architecture
Files are split into blocks at write time. The default block size of one hundred twenty-eight megabytes was chosen to keep NameNode metadata small while making sequential streaming efficient on rotational disks. Each block has a unique identifier, a version number, and a CRC checksum. Blocks are stored as ordinary files on the local Linux filesystem of each DataNode, one file for the block data and one for its metadata.
Every block has a replication factor. The default is three. This is expressed as a keyspace-wide default in hdfs-site.xml and can be overridden per file. Once a file is written, the NameNode is responsible for maintaining the target replication factor over time by scheduling replication when a DataNode fails and by pruning excess replicas when a formerly-dead node returns to service.
How it works end to end
When a client writes a new block, it contacts the NameNode and asks for three DataNode targets. The NameNode consults its topology map and picks nodes according to the default policy: one on the same rack as the writer if possible, then two on a different rack. The two remote-rack replicas land on the same second rack so that reads from that rack can be satisfied without leaving the rack once you have contacted it. The client opens a pipeline: it sends bytes to the first DataNode, which forwards to the second, which forwards to the third. Each hop adds forwarding latency but only one crosses rack boundaries in the whole pipeline.
When a DataNode dies, its blocks become under-replicated. The NameNode notices this during the next block report and schedules replication: for each under-replicated block, it picks a source replica and a target DataNode following the same placement rule, then instructs the source to send the block to the target. This background replication traffic is rate-limited by dfs.namenode.replication.max-streams so that it does not saturate the cluster during a large-scale failure event.
Reads are served by picking whichever replica is nearest to the client. HDFS considers same-node first, then same-rack, then any-rack. The NameNode returns an ordered list of replica locations, and the client tries them in order until one responds. This is how you get local-rack reads with no explicit tuning: the placement policy guarantees at least one local-rack replica exists whenever the writer was in the cluster.