Distributed File System

CAP Theorem: distributed systems can guarantee at most two of: Consistency (all nodes see same data), Availability (system responds to all requests), Partition tolerance (continues despite network splits). Network partitions are inevitable in distributed systems, so choose CP (consistent, may refuse requests during partition — like ZooKeeper) or AP (available, may return stale data during partition — like Cassandra). This DFS chooses CP: strong consistency using Raft consensus.

Raft provides distributed consensus for replicated log. Leader election: nodes start as followers. On timeout (150–300ms random), candidate requests votes. Wins if majority votes received. Leader sends heartbeats to prevent re-elections. Log replication: client writes go to leader. Leader appends to log, sends AppendEntries RPC to followers. When majority acknowledge, leader commits entry, applies to state machine, responds to client. Failure: if leader fails, new election occurs after timeout.

Map file system operations to state machine commands: WRITE_FILE(path, data) → Raft log entry → applied to all nodes. DELETE_FILE(path) → log entry. Metadata stored in Raft-replicated log (file name, size, checksum, creation time). File data: chunked into 4MB blocks, stored locally on each node (replicated by Raft log). Small files (< 64KB): inline in log entry. Large files: stored in local LevelDB by content-hash, referenced in log.

Test with Docker: run 5-node cluster. Kill leader process → verify new leader elected within 2 seconds, cluster continues serving requests. Kill 2 of 5 nodes → cluster maintains quorum (3/5), continues. Kill 3 of 5 → no quorum, cluster halts (CP guarantee). Network partition: split into 2+3 groups → 3-node partition maintains quorum and continues, 2-node partition rejects requests. Restore network → 2-node group syncs from 3-node leader.