Software RAID with mdadm

Linux Filesystems

Chapter 8 · Software RAID with mdadm

fs1-7 covered the levels and their tradeoffs conceptually. This chapter is the real tool Linux uses to build and manage them: mdadm ("multiple disk admin"), and a full, real walkthrough of the moment a RAID array actually earns its keep — a disk failing and getting replaced.

Creating a RAID Array

# RAID 1 (mirroring) across two partitions
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1

# RAID 5 (striping + distributed parity) across three partitions
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1

mkfs.ext4 /dev/md0
mount /dev/md0 /mnt/raid

--level and --raid-devices map directly onto fs1-7's own concepts — --level=1 is mirroring, --level=5 is striping with one distributed parity block, and so on. Once created, /dev/md0 behaves like any other block device — format it and mount it directly, or, per fs1-5, put LVM on top of it instead of formatting it directly (the full layered stack is covered in fs1-9).

Persisting the Array Configuration

mdadm --detail --scan >> /etc/mdadm/mdadm.conf
update-initramfs -u

Without writing the array's own configuration to mdadm.conf, the array may not reassemble correctly — or with the wrong device ordering — on the next reboot. This is an easy step to forget right after --create succeeds and everything appears to be working. update-initramfs -u ensures the initramfs itself knows how to assemble the array early in the boot process, which matters especially when the root filesystem itself lives on RAID.

Monitoring Array Health

cat /proc/mdstat

The primary, always-available way to check array status. Shows every active array, its member disks, and a health indicator like [UU] — each letter represents one member disk, U meaning up/healthy, an underscore meaning missing or failed. A RAID 5 array showing [UU_] instead of [UUU] is degraded, missing exactly the redundancy fs1-7 covered.

mdadm --detail /dev/md0

Fuller detail than /proc/mdstat — array state, rebuild progress, and event count. For genuine production use, mdadm --monitor --scan can run as a daemon that emails an alert the moment an array degrades or a disk fails, rather than relying on someone remembering to check manually.

A Real Disk Failure Simulation

# mark a member as failed
mdadm /dev/md0 --fail /dev/sdc1
cat /proc/mdstat                    # now shows a degraded array, e.g. [U_]

# remove the failed member before physically pulling the disk
mdadm /dev/md0 --remove /dev/sdc1

# -- physically replace the disk, partition the new one to match --

# add the replacement — triggers an automatic rebuild
mdadm /dev/md0 --add /dev/sdc1
cat /proc/mdstat                    # shows "recovering", a percentage, speed, and ETA

The Rebuild Window in Practice

Watching /proc/mdstat climb through a RAID 5 rebuild is fs1-7's own rebuild-risk warning made concrete: while the state shows recovering and a percentage ticking upward, the array is running with zero further redundancy for a RAID 5 array — exactly the exposed window fs1-7 warned about, now visible directly in the monitoring output rather than as an abstract risk.

Command	Purpose
mdadm --create	Build a new array from raw disks/partitions
mdadm --detail --scan	Print config for persisting to mdadm.conf
cat /proc/mdstat	Quick array status and health at a glance
mdadm --detail	Full status: state, rebuild progress, events
mdadm --fail / --remove / --add	The failed-disk replacement sequence

Persist the config right after creation, not "later"

Run mdadm --detail --scan >> /etc/mdadm/mdadm.conf immediately after mdadm --create succeeds — it's easy to forget once the array is already working, and the gap only becomes visible at the worst possible time: the next reboot.

Never pull a disk before --fail and --remove

Physically removing a disk from a live array before both --fail and --remove have been run against it leaves Linux potentially still attempting I/O against a device that's already physically gone — a real path to an unclean array state and additional corruption risk, on top of whatever originally prompted the disk's removal.

Hands-On Exercises

Exercise 1

Write the full mdadm command to create a RAID 6 array named /dev/md0 from four disks: /dev/sdb1, /dev/sdc1, /dev/sdd1, /dev/sde1. Cross-check the resulting usable capacity against fs1-7's own compare-table.

📄 View solution

Exercise 2

An administrator creates a new mdadm array, formats and mounts it successfully, but skips writing its configuration to mdadm.conf. Explain what's likely to go wrong, and when.

📄 View solution

Exercise 3

An administrator notices a disk showing signs of failure and, wanting to act fast, immediately pulls it out of the running server without running any mdadm commands first. Explain what this chapter warns is risky about that, and what the correct sequence would have been.

📄 View solution

Chapter 8 Quick Reference

mdadm --create /dev/mdX --level=N --raid-devices=N <devices> — build an array
mdadm --detail --scan >> /etc/mdadm/mdadm.conf — persist the config immediately, not later
update-initramfs -u — needed if root itself lives on the array
cat /proc/mdstat — quick health check, [UU] vs. [U_]
mdadm --detail /dev/mdX — full state, rebuild progress, event count
Failed-disk sequence: --fail, then --remove, then physically replace, then --add
Never physically pull a disk before --fail/--remove — risks an unclean array state
Watching a RAID 5 rebuild in /proc/mdstat makes fs1-7's own rebuild-window risk directly visible