Compare JBOD vs RAID for Kafka brokers and explain why XFS is commonly recommended over ext4.
answer
- JBOD = each disk in log.dirs, replication = redundancy
- RAID10 redundancy + even I/O, ~50% capacity cost
- Avoid RAID5/6 (write penalty)
- XFS > ext4 for big-file high-throughput writes
- Mount noatime
basics
~20 sJBOD gives Kafka each disk separately via log.dirs, so failures are isolated and replication handles redundancy; RAID (often RAID10) adds redundancy and even I/O but costs capacity/write speed. XFS is favored over ext4 for better performance under Kafka's large sequential-write workload.
solid answer
~50 sJBOD ('just a bunch of disks') exposes each drive as its own mount; you list them all in log.dirs and Kafka spreads partitions across them. A single disk failure only loses the partition replicas on that disk, which replication re-builds elsewhere — Kafka can even keep the broker online for other disks. JBOD wastes no capacity on redundancy and avoids RAID write penalties, which is why large deployments favor it; the cost is that Kafka must manage balancing and a disk failure historically had rough edges. RAID (commonly RAID10) gives the OS one logical volume with hardware redundancy and smooths hot-spotting, but you pay ~50% capacity for mirroring and incur write amplification; RAID5/6 are avoided due to the write penalty. For the filesystem, XFS is the common recommendation over ext4: it handles Kafka's many large files and high-throughput sequential/parallel writes with better scalability and lower lock contention, and benchmarks generally show it ahead under Kafka-like load. Both should be mounted noatime.
go deeper
Know JBOD = multiple disks in log.dirs, RAID = one redundant volume; XFS is the common pick.
Explain that replication is JBOD's redundancy and why RAID10 (not 5/6) is the RAID choice.
Discuss capacity/write-penalty tradeoffs, intra-broker disk balancing, and XFS-vs-ext4 under Kafka's write profile plus noatime.
Architect storage for failure blast-radius, cost, and throughput at scale — when replication makes RAID redundant vs when operational simplicity justifies it.
## Storage layout: JBOD vs RAID Kafka writes each partition as a sequence of large, append-only log segment files. How those files map onto physical disks is a deployment choice. **JBOD ('Just a Bunch Of Disks').** Each physical disk is a separate filesystem/mount, and you list every mount in the broker's `log.dirs` (comma-separated). Kafka places partitions across the directories itself. - *Redundancy:* none at the disk layer — Kafka's **replication** is the redundancy. If one disk dies, only the partition replicas stored on it are lost, and the cluster re-replicates them from other brokers. With modern Kafka, a single failed log dir doesn't have to take the whole broker down; the broker can keep serving partitions on healthy disks. - *Pros:* no capacity sacrificed to mirroring/parity, no RAID write penalty, full aggregate disk bandwidth, failure blast-radius limited to one disk. This is why very large clusters (e.g., LinkedIn-scale) historically run JBOD. - *Cons:* Kafka must balance load across disks (intra-broker partition placement), and uneven partition sizes can hot-spot a single disk. **RAID (usually RAID10).** The OS sees one logical volume; the RAID layer handles striping + mirroring. - *Pros:* disk-level redundancy independent of Kafka, and striping evens out per-disk hot spots so one heavy partition doesn't saturate a single spindle. Simpler from Kafka's view (one big `log.dir`). - *Cons:* RAID10 costs ~50% of raw capacity to mirroring and adds write amplification; a controller can be a bottleneck. **RAID5/6 are discouraged** for Kafka — their parity recomputation imposes a heavy write penalty that clashes with Kafka's write-heavy profile. **Rule of thumb:** Because Kafka already replicates across brokers, paying again for RAID redundancy is often redundant; large throughput-oriented clusters prefer JBOD, while RAID10 is chosen when operators want hardware redundancy / simpler disk management and can absorb the capacity cost. ## Filesystem: why XFS over ext4 Both XFS and ext4 are mature Linux journaling filesystems and both work. Kafka's workload is distinctive: a relatively small number of very large files, heavy sequential appends, lots of concurrent writers (many partitions), and frequent segment rolls. - **XFS** was designed for large files and high parallel throughput; it scales better under heavy concurrent write load and tends to have lower lock contention, and its allocation behavior suits large sequential files. The Kafka community and benchmarks (including Confluent's) generally recommend **XFS** as the default and report it outperforming ext4 under Kafka-like load. - **ext4** is perfectly usable and slightly more ubiquitous, but can show more contention/latency variance at Kafka's throughput; if used, tuning (e.g., `data=writeback`) is sometimes applied. - **Mount option:** mount with **`noatime`** on either FS so reads don't trigger metadata writes for access-time updates — pure waste for Kafka. ## Edge cases / pitfalls - On JBOD, neglecting intra-broker balance lets one disk fill or saturate while others idle; use Kafka's disk-aware placement / rebalancing. - RAID5/6 in front of Kafka is a frequent anti-pattern — the parity write penalty cripples write throughput. - Filesystem choice matters far less than having enough RAM for page cache and fast disks; XFS-vs-ext4 is a refinement, not a rescue for an undersized box.
- Why is RAID5/6 a poor fit for Kafka?Parity recomputation on every write creates a large write penalty (write amplification), which clashes with Kafka's write-heavy sequential-append workload.
- If you run JBOD and a disk fails, what happens to availability?Only the partition replicas on that disk are lost; modern Kafka keeps the broker serving its other log dirs, and the cluster re-replicates the affected partitions from other brokers.
saying these in an interview costs you the question
- Recommending RAID5/6 in front of Kafka.
- Thinking JBOD has no redundancy at all — it relies on Kafka replication.
- Claiming filesystem choice matters more than RAM/page cache and disk speed.
- Forgetting noatime / treating ext4 as unusable (it works, XFS is just preferred).