Learn RAID - Advanced mdadm Features

#Introduction

Up to episode 16 we used the basic features and crisis handling. Episode 17 brings up mdadm features that are rarely discussed but hugely important for array resilience: bitmap, write-intent journal, and consistency policy. All three answer one fundamental question: what happens when the power dies mid-write?

Without these mechanisms, after a crash you'd have to do a full array-wide sync — taking hours. With a bitmap and journal, the process narrows to only the blocks that actually changed. Let's break each one down.

#Internal Bitmap

#What Is an Internal Bitmap

A bitmap is a small map that records which blocks might be out of sync between disks. When a crash happens mid-write, the kernel uses the bitmap to mark the stripes being written. After reboot, synchronization only touches the marked blocks — not the whole array.

sudo mdadm --detail /dev/md0 | grep -i bitmap

The mdadm --detail output shows a Bitmap : 24328 blocks (95 MB) line. If this line is missing, your array isn't using a bitmap — and every crash forces a full sync.

#Adding a Bitmap

For an array created without a bitmap, you can add one:

sudo mdadm --grow /dev/md0 --bitmap=internal

The mdadm --grow --bitmap=internal command enables a bitmap inside the array's superblock. This operation is fast and doesn't change data. Its effect is felt on a crash: the rebuild becomes a much shorter partial resync.

#The Cost of a Bitmap

A bitmap isn't free. Every write must now update the map, adding a little I/O overhead. For arrays with very heavy write workloads, measure the impact with iostat before and after. This overhead is usually imperceptible, but good to know.

#Lockless Bitmap in mdadm 4.6

#The Conventional Bitmap Problem

Traditional bitmaps use locking when updated — one write waits for another to finish updating the map. On heavy write workloads, this lock can become a bottleneck and add write latency.

#Lockless Bitmap

mdadm 4.6 (March 2026) introduces the lockless bitmap, which updates the map without locking the whole structure. The result: bitmap overhead drops drastically on high-speed writes:

mdadm --version

The mdadm --version output must show 4.6 or newer to use the lockless bitmap. This feature bridges the gap between crash protection and high write performance — which previously required choosing one or the other.

#When to Use It

The lockless bitmap is most valuable on arrays with write-heavy workloads that also need crash protection, such as databases and VM storage. For arrays with infrequent writes, the performance difference is small.

#Write-intent Journal

#The Parity Write Hole Problem

We already mentioned the write hole in episode 8: when a crash happens mid-stripe-write, data and parity can go out of sync on RAID 4, 5, and 6. mdadm has two answers: a bitmap speeds up synchronization, but doesn't fully close the inconsistency window.

The write-intent journal closes that hole by recording the write intent to a separate log device (usually a small SSD) before writing the stripe. On a crash, the kernel uses the journal to know exactly what needs to be completed.

#Adding a Journal

sudo mdadm --add-journal /dev/md0 /dev/sdd
sudo mdadm --detail /dev/md0 | grep -i journal

The mdadm --add-journal /dev/md0 /dev/sdd command adds /dev/sdd as a journal device. The --detail output shows a Journal : /dev/sdd section. The journal must have adequate capacity (around 128M to 512M) and ideally use fast media like an SSD.

#Journal Impact

The journal's main benefits:

• Write hole protection: a crash no longer leaves a parity array inconsistent.
• Faster rebuild after a crash: no need to scan the entire array.
• Better stability for RAID 5 and 6.

The costs: one extra device and write overhead for recording the intent.

#Consistency Policy

#Configuring Synchronization Behavior

--consistency-policy determines the synchronization mechanism the array uses:

sudo mdadm --grow /dev/md0 --consistency-policy=journal
sudo mdadm --detail /dev/md0 | grep -i consistency

Available values include:

• resync: no bitmap — full sync after a crash.
• bitmap: uses an internal bitmap for partial resync.
• journal: uses a write-intent journal for full protection.
• ppl (RAID 5): Partial Parity Log, records partial parity on the member devices.

The --detail output shows Consistency Policy : journal. Choose the policy according to your priorities: rebuild speed or full protection against the write hole.

#Saving the Configuration

After adding a bitmap, journal, or changing the policy, don't forget to save the configuration:

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm.conf
sudo update-initramfs -u

The mdadm --detail --scan command prints an ARRAY line that already includes the active features; update-initramfs -u makes sure the initramfs knows the latest configuration at boot.

#Conclusion

Episode 17 opened up the advanced mdadm features that keep an array stable and quick to recover after disruptions: internal bitmap for partial resync, the lockless bitmap in mdadm 4.6 for heavy writes, the write-intent journal for closing the write hole, and the consistency policy to manage it all.

Key takeaways:

• A bitmap limits post-crash resync to only the changed blocks.
• The mdadm 4.6 lockless bitmap reduces bitmap overhead on heavy writes.
• The write-intent journal closes the write hole on RAID 4, 5, and 6.
• PPL is a journal alternative specific to RAID 5 using member disks.
• Consistency policy configures the array's synchronization mechanism.
• Save changes to mdadm.conf and update the initramfs.

In the next episode, episode 18, we'll discuss performance tuning — adjusting the chunk size and stripe cache, choosing a parity algorithm and I/O scheduler, and measuring the impact with fio and dd. You'll learn to make an array that's genuinely fast for your workload.