Learn RAID - RAID 10 & Performance Workloads

#Introduction

Up to episode 8 we covered RAID parity and RAIDZ. Episode 9 looks at the opposite: for workloads demanding high performance, many teams actually choose RAID 10 — a combination of mirroring and striping that trades away some capacity for speed and short rebuilds.

Why do databases and VMs dominate the RAID 10 discussion? Because both are full of random I/O — small, non-sequential reads and writes. In such workloads, the parity of RAID 5 or 6 becomes a burden. Let's break down how it works, its strengths, and when RAID 10 is the right choice.

#How RAID 10 Works

#Mirror First, Then Stripe

RAID 10 (also written RAID 1+0) builds two layers: disks are paired as mirrors, then all pairs are combined with striping. With four disks, the resulting structure is two mirrors that are striped.

sudo mdadm --create /dev/md0 --level=10 --raid-devices=4 /dev/sdb /dev/sdc /dev/sdd /dev/sde

The mdadm --create --level=10 command above creates a RAID 10 array. The /proc/mdstat output shows md0 : active raid10 sde[3] sdd[2] sdc[1] sdb[0]. Its capacity is N/2 — half of the total physical capacity.

#Fast Rebuilds

RAID 10's biggest strength is rebuild speed. When one disk fails, data doesn't need to be recalculated from parity — it just needs to be copied from its mirror pair. This makes the window of vulnerability much shorter than RAID 5 or RAIDZ on large arrays.

#Why Databases and VMs Love It

#Random I/O Performance

Databases (PostgreSQL, MySQL, and others) and VM disks are full of small random read-write operations. On RAID 10, random writes are distributed across mirror pairs without computing parity — every write is "cheap". This is the fundamental difference from RAID 5 and 6, which must perform a read-modify-write for parity.

#Calculating IOPS

IOPS (Input/Output Operations Per Second) is the primary metric for this kind of workload. A simple estimate:

total_IOPS ≈ number_of_pairs * IOPS_per_disk * 2 (for reads)
total_IOPS ≈ number_of_pairs * IOPS_per_disk (for writes, fully loaded)

The concept: with N disks in mirrored pairs, reads can spread across all disks, while random writes are limited to each pair. This is why for databases, RAID 10 with HDDs can significantly outperform RAID 5 throughput.

#VM Storage and Hypervisors

For hypervisors hosting many VMs, I/O demand is very unpredictable. RAID 10 gives stable, low-cost latency for mixed workloads — which is why it's the standard in many Proxmox and KVM setups. Striping guarantees distribution, mirroring guarantees resilience.

#Latency and Write Load

#Read-modify-write with Parity

Every small write on RAID 5 and 6 forces the system to read the existing data block, compute the new parity, then write to two locations. This cycle is called read-modify-write — and each step adds latency. On workloads full of small random writes, this overhead happens constantly.

small write → read old data + parity → compute new parity → write data → write parity

RAID 10 avoids this flow entirely: writes are simply forwarded to a mirror pair without any parity calculation. This is the fundamental reason RAID 10 feels faster on random writes — not because the disks are faster, but because the path is shorter.

#Consistent Latency

Another often-overlooked RAID 10 advantage: consistent latency. On parity RAID, write latency rises when the stripe cache fills up or when many stripes share a single parity disk. RAID 10 distributes writes to pairs that are ready, so the latency distribution is narrower and more predictable — highly valuable for transactional applications sensitive to outliers.

#When to Choose RAID 10 vs RAIDZ vs RAID 6

#Comparison Table

#Practical Rules

• Choose RAID 10 if your workload is dominated by random I/O and writes — transactional databases, VMs, and containers.
• Choose RAIDZ2 or RAID 6 if you prioritize maximum capacity and mostly sequential I/O — media servers, archives, backups.
• Choose RAIDZ if data integrity and self-healing are the priority, and the workload isn't too demanding on random writes.

lsblk -o NAME,SIZE,TYPE,FSTYPE
df -h /dev/md0

The lsblk and df -h output helps you verify capacity calculations before deciding on a level. Get in the habit of calculating on paper first, then executing the commands.

#A Quick Case Study

Imagine a 500GB transactional database on a server with four 4TB disks. Option A: RAID 10 with 8TB capacity, fast rebuilds, optimal random writes. Option B: RAIDZ2 with 8TB capacity, checksums plus self-healing, but heavier random writes and longer rebuilds. For a database chasing low latency and uptime, option A almost always wins; for a dataset that's rarely written but expensive to lose, option B is the saner choice.

#Conclusion

Episode 9 explained RAID 10's position in the spectrum of choices: it's the primary choice for workloads with random I/O and heavy writes like databases and VMs, at the price of half the capacity. You also know when to switch to RAIDZ2 or RAID 6 for capacity and integrity.

Key takeaways:

• RAID 10 is mirror-plus-stripe with N/2 capacity.
• RAID 10 rebuilds are fast because you just copy from the mirror pair.
• Databases and VMs love RAID 10 because random writes are cheap without parity.
• RAIDZ2 and RAID 6 suit capacity and sequential workloads better.
• IOPS is the key metric for comparing levels on transactional workloads.
• Measure your workload first, then choose the level — don't choose based on the name.

In the next episode, episode 10, we'll discuss RAID for SSD/NVMe — TRIM and discard on arrays, wear-leveling, parity overhead for SSDs, and the roles of SLOG/ZIL and L2ARC in ZFS. You'll understand the fundamental differences of managing RAID on top of solid-state media.