What Is mdraid? Core Concepts
mdraid (often shortened to MD RAID or simply md) is the Linux kernel’s built‑in software RAID framework. It aggregates multiple block devices (drives, partitions, loopbacks, NVMe namespaces, etc.) into a single logical block device (/dev/mdX) that can deliver improved performance, redundancy, capacity aggregation — or some combination — depending on the selected RAID level.
At its heart, mdraid:
· Lives primarily in the Linux kernel as the md (Multiple Device) driver.
· Uses on‑disk superblock metadata to describe array membership and layout.
· Exposes assembled arrays as standard block devices that can be partitioned, formatted, LVM’ed, encrypted, or used directly by applications.
In other words: mdraid is the engine; mdadm is the toolkit and dashboard.
How mdraid Fits in the Linux Storage Stack
A simplified vertical stack (bottom → top):
[Physical / Virtual Drives]
SATA / SAS / NVMe / iSCSI LUNs / VMDKs / Cloud Block Vols
↓
[mdraid Kernel Layer] ← assembled via mdadm
RAID0 | RAID1 | RAID4/5/6 | RAID10 | RAID1E | linear | multipath | etc.
↓
[Optional Layers]
LUKS dm-crypt | LVM PV/VG/LV (incl. LVM-thin) | Filesystems (ext4, XFS, btrfs, ZFS-on-Linux as zvol consumer, etc.)
↓
[Applications / Containers / VMs]
Because md devices appear as regular block devices, you can build rich storage stacks: encrypt then RAID, RAID then encrypt, layer LVM for flexible volume management, or present md devices to virtualization hosts.
mdadm vs mdraid: Terminology Clarified
Remember: You manage arrays with mdadm; the arrays themselves are provided by the mdraid kernel layer.
Supported RAID Levels & Modes
mdraid supports a broad set of personalities (RAID implementations). Availability may vary slightly by kernel version, but common ones include:
· linear — Concatenate devices end‑to‑end; no redundancy.
· RAID 0 (striping) — Performance & aggregate capacity; zero redundancy.
· RAID 1 (mirroring) — Redundancy via copies; read parallelism.
· RAID 4 — Dedicated parity disk; rarely used.
· RAID 5 — Distributed parity across members; 1‑disk fault tolerance.
· RAID 6 — Dual distributed parity; 2‑disk fault tolerance.
· RAID 10 — Striped mirrors (mdraid implements as an n‑way layout over mirrored sets; flexible). Good mix of speed + redundancy.
· RAID 1E / RAID 10 variants — Extended / asymmetric mirror‑stripe layouts for odd numbers of drives.
· Multipath — md can be used (less common today) to provide failover across multiple I/O paths.
· Faulty — Testing personality that injects failures.
Key Architecture Elements
Superblock Metadata — Small headers stored on member devices that describe array UUID, RAID level, layout, chunk size, role of each device, and state.
md Personalities — RAID level implementations registered with the kernel’s md subsystem.
Bitmaps — Optional on‑disk or in‑memory bitmaps track which stripes are dirty, dramatically shortening resync/recovery after unclean shutdowns.
Reshape Engine — Allows changing array geometry (add/remove devices, change RAID level in some cases) online in many scenarios. Performance impact can be significant; plan maintenance windows.
mdmon (External Metadata Monitor) — Required for some external metadata formats (e.g., IMSM/Intel Matrix) to keep metadata in sync.
Sysfs Controls — Tunables under /sys/block/mdX/md/ expose runtime parameters (stripe cache, sync speed limits, write‑mostly flags, etc.).
Common Use Cases
· Homelab NAS or DIY storage server using commodity disks.
· Bootable mirrors (RAID1) for root filesystem resiliency.
· RAID10 for database or virtualization workloads needing strong random I/O + redundancy.
· RAID5/6 for bulk capacity with parity protection (backup targets, media libraries — though see risk discussion below on rebuild windows and URE rates).
· Aggregating NVMe drives when hardware RAID isn’t desired or available.
· Cloud or virtual environments where virtual disks need software‑defined redundancy across failure domains.
Planning an mdraid Deployment
Before typing mdadm — create, answer these:
1. Workload Profile
Random vs sequential; read‑heavy vs write‑heavy; mixed DB + VM vs cold archive.
2. Redundancy vs Capacity
How many failures must you tolerate? RAID1/10 vs RAID5/6 trade‑offs.
3. Media Type
HDD, SSD, NVMe, or mixed? Parity RAID on SSD behaves differently (write amplification, TRIM behavior, queue depth scaling).
4. Growth Expectations
Will you add drives later? Consider RAID10 or start with larger drive count in RAID6; know reshape implications.
5. Boot Requirements
If booting from md, choose metadata format (0.90 or 1.0) that places superblock where firmware/bootloader expects.
6. Monitoring & Alerting Plan
Email alerts, systemd timers, mdadm — monitor, integration with Prometheus/node_exporter, etc.
7. Backup Strategy
RAID ≠ backup. Always maintain off‑array copies of critical data.
More & posted from: https://medium.com/@pltnvs/the-definitive-guide-to-mdraid-mdadm-and-linux-software-raid-fbb561c21878