GFS was designed with specific workload assumptions:
  1. Files are LARGE (multi-GB). Small files exist but aren't optimized for.
  2. Reads are mostly SEQUENTIAL (streaming). Random reads are rare.
  3. Writes are mostly APPENDS (log files, analytics output). Random writes are rare.
  4. Hardware FAILS regularly (commodity servers, cheap disks).
  5. High sustained THROUGHPUT is more important than low LATENCY.

These assumptions drive every design decision.
Contrast with: traditional file systems (small files, random I/O, low latency).

Chunk (Block):
  - Files split into fixed-size chunks (64 MB in GFS, 128 MB in HDFS)
  - Each chunk stored as a regular Linux file on a chunk server
  - Each chunk replicated to 3 chunk servers (default)
  - Chunk identified by globally unique 64-bit chunk handle

Why 64-128 MB chunks?
  - Reduces metadata on master (1 PB / 64 MB = 16M chunks, manageable in RAM)
  - Reduces client-master interactions (fewer chunks to look up)
  - Enables large sequential I/O (read an entire chunk without seeking)
  - Trade-off: small files waste space (a 1 KB file still occupies a chunk entry)

Master (NameNode):
  - Single node (simplified, but single point of failure)
  - Stores ALL metadata in memory:
    → Namespace (directory tree): ~64 bytes per file/directory
    → File → chunk mapping: ~64 bytes per chunk
    → Chunk → location mapping: from chunk server heartbeats (not persisted)
  - 1 PB of data → ~16M chunks → ~1 GB of metadata → fits in RAM easily

The master is a single point of failure. How to protect it?

1. Operation Log (WAL):
   - Every metadata mutation logged to disk BEFORE responding
   - Log replicated to remote backup machines
   - On master crash → new master replays operation log

2. Checkpoints:
   - Periodically snapshot the in-memory metadata to disk
   - Compact B-tree format for fast loading
   - Recovery: load latest checkpoint + replay log entries after checkpoint

3. Shadow Masters (Stanby NameNode):
   - Read replicas of the master
   - Serve read-only metadata requests (slightly stale)
   - Can be promoted to primary on master failure

4. HDFS HA (modern approach):
   - Active/Standby NameNode pair
   - Shared edit log via JournalNodes (Quorum-based)
   - ZooKeeper for automatic failover
   - Failover time: 30-60 seconds

Chunk location data is NOT persisted by master:
   - Chunk servers report their chunks via heartbeats on startup
   - Master rebuilds chunk→location map from heartbeats
   - This simplifies master recovery (less state to persist)

Detection:
  - Chunk server sends heartbeat to master every 3 seconds
  - No heartbeat for 30 seconds → master marks server as dead

Recovery:
  - Master identifies under-replicated chunks (< 3 replicas)
  - Prioritizes: chunks with 1 replica > chunks with 2 replicas
  - Instructs healthy chunk servers to copy chunks
  - Respects rack-awareness: replicas spread across racks

Rack-aware placement (default):
  Replica 1: same rack as writer (low latency)
  Replica 2: different rack (survives rack failure)
  Replica 3: same rack as replica 2 but different node

This survives: 1 node failure, 1 rack failure, 1 disk failure.