Right, let’s get our hands dirty with mdadm. This isn’t some glossy GUI wizard that hides the messy bits from you; this is the command-line power tool that actually builds the arrays. Think of it as the difference between ordering a pre-made sandwich and being handed a knife, a fresh loaf, and the finest ingredients. More work? Absolutely. But you get exactly what you want, and you know it’s made right.

The Core Concept: Creation, Assembly, and the Conf File

First, wrap your head around this: creating an array and assembling an array are two different dances. When you --create, you’re building the array from scratch, writing the superblock to each member disk. This superblock is the little note mdadm leaves on each drive that says, “Hi, I’m part of this specific array with these other drives.” It’s the metadata that makes everything else possible.

Once an array exists, you don’t create it again. You --assemble it. This command looks at the superblocks on the drives you specify (or goes on a scavenger hunt for them) and puts the band back together. This is why your arrays magically come back to life after a reboot—a system startup script runs mdadm --assemble --scan.

Which brings us to the most important best practice: /etc/mdadm/mdadm.conf. This file is the stage manager for your arrays. After you create an array, dump its configuration into this file:

# Capture the current layout of your arrays and append it to the config file
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf

Why bother? Because --assemble --scan reads this file. It knows what to look for and what to call the assembled array (e.g., /dev/md0). Without this, your system might accidentally reassemble arrays with different names, which is a fantastic way to ruin your day and your filesystem. Consider this file non-optional.

Creating Your First RAID Array

Let’s create a RAID 1 (mirror) array. You’ve got two disks, /dev/sdb and /dev/sdc, and you want them to be /dev/md0. Here’s the incantation:

sudo mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc

Break it down:

  • --create: We’re building new.
  • /dev/md0: The name of the array device we’re creating.
  • --level=1: RAID 1, mirroring.
  • --raid-devices=2: We’re using two devices for this array.
  • /dev/sdb /dev/sdc: The brave volunteers.

Now, watch the output. It will kick off a recovery process. Wait, what? You just created it! Yes, and mdadm is now diligently copying the blocks from one drive to the other to synchronize them. You can watch this beautiful, paranoid process with:

cat /proc/mdstat

You’ll see something like Personalities : [raid1] and md0 : active raid1 sdc[1] sdb[0] followed by [=========>...........] recovery = 45.2% (1234567890/2345678901) finish=2.0min speed=12345K/sec. Let it finish. Don’t try to put a filesystem on it until it’s done. Go get a coffee.

The Critical Details: Chunk Sizes and Filesystems

RAID 0, 5, 6, and 10 use striping. The size of these stripes is called the chunk size. This isn’t some arbitrary number you leave as default. Picking the wrong chunk size can murder your performance.

  • Large chunks (e.g., 512K-1M): Great for large, sequential reads/writes (video editing, large file storage).
  • Small chunks (e.g., 64K-128K): Better for small, random I/O (databases, virtual machines).

The default is often 512K, which is a decent middle ground but rarely optimal. Think about your workload. For a general-purpose filesystem that will host a database and large media files, 256K is a pretty sane choice. You set it at creation time:

sudo mdadm --create /dev/md0 --level=5 --chunk=256 --raid-devices=3 /dev/sdb /dev/sdc /dev/sdd

Once your array is built and synced, then you put a filesystem on it. ext4? XFS? btrfs? That’s a holy war for another chapter. Just remember: never use /dev/sdb or /dev/sdc directly again. You interact only with /dev/md0. The array is your disk now.

Managing the Beast: Failures and Smart Removal

This is where RAID earns its keep. Let’s simulate a drive failure. First, mark a drive as faulty:

sudo mdadm /dev/md0 --fail /dev/sdc

Check /proc/mdstat again. You’ll see an (F) next to sdc. The array is now running in a degraded state. Your data is still accessible (thanks to the mirror or parity), but you’re on borrowed time. Now, remove the failed drive from the array:

sudo mdadm /dev/md0 --remove /dev/sdc

Physically yank the drive out. Now, slide a new, blank drive in. Let’s say the system sees it as /dev/sde. You add it to the array to start the rebuild:

sudo mdadm /dev/md0 --add /dev/sde

Check /proc/mdstat one more time. The recovery will start automatically. The array will rebuild the data onto the new member from the remaining good drive(s). Your brilliant redundancy is restored. This process is exactly the same for RAID 5 or 6; you’re just rebuilding from parity instead of a direct mirror.

The “Oh Crap” Moment: Stopping and Reassembling

Sometimes you need to tear down an array completely. Maybe you’re re-provisioning. WARNING: This will make the data on the array inaccessible. First, unmount the filesystem, then stop the array:

sudo umount /mnt/raid
sudo mdadm --stop /dev/md0

Poof. /dev/md0 is gone. But the superblocks are still on the drives (/dev/sdb, /dev/sdc, etc.). If you want to reassemble it later, that mdadm.conf file we made becomes your best friend:

sudo mdadm --assemble --scan

This command will look at the config, find all the arrays defined there, find the drives with matching superblocks, and assemble them all. It’s magic, but it’s the kind of magic you meticulously set up yourself. Never skip the config file. It’s the difference between a clean reassembly and a frantic late-night debugging session trying to remember which drive was which. Trust me, I’ve been both people. Be the first one.