RAID Parity Rebuild Stalled – Fixes That Actually Work

You're watching the progress bar sit still. It's infuriating.

RAID parity rebuilds stall because the controller or mdadm hits a read error it can't bypass, or a disk drops offline due to timeout. Here's the fix that works in 90% of cases, then the why.

The Primary Fix

Identify the slacker disk. Check logs: dmesg | grep -i 'read error' or your controller's event viewer. On hardware RAID, look for "Medium Error" or "Check Condition". On mdadm: mdadm --detail /dev/md0 shows which device has errors.
Force the array to skip bad blocks.
- For mdadm: echo 'repair' > /sys/block/md0/md/sync_action then echo 'check' > /sys/block/md0/md/sync_action — this forces mdadm to rewrite parity and clear the stuck state.
- For hardware RAID (LSI/Broadcom): storcli /c0/e0/s0 set force online after you've identified the disk, then do a consistency check in the controller utility.
Increase the error recovery timeout. Many consumer drives (WD Red, Seagate IronWolf) have a default 7-second recovery try—too short for RAID. Use smartctl or a utility like hdparm to set TLER (Time-Limited Error Recovery) to 7 seconds on each disk—yes, 7 is the sweet spot. On Seagate: smartctl -l scterc /dev/sda to check, then smartctl -l scterc,70,70 /dev/sda to set. For WD: use wdidle3 to disable idle timeout, but TLER is usually set via smartctl -l scterc,70,70 if supported.
Restart the rebuild: For mdadm, mdadm --assemble --scan; mdadm --readwrite /dev/md0 then force sync again. For hardware, power cycle the chassis (not the drives), then start consistency check.

Why This Works

What's actually happening here is a single bad sector on one disk causes the controller or mdadm to retry indefinitely. The array is designed to handle one disk failure, but a read error that can't be bypassed stalls the parity calculation—the controller doesn't know whether to use old parity or new data, so it locks up. By forcing a repair action (which rewrites parity from the other disks, ignoring the bad block) or increasing the error recovery timeout, you let the controller skip the bad sector and continue. The reason step 3 works is that consumer drives spend too long retrying a read before reporting failure—the RAID controller gives up waiting and drops the drive. Set TLER to 7 seconds, and the drive reports failure fast enough that the RAID firmware marks the block bad and moves on.

Less Common Variations

Scenario	Fix
mdadm shows "resync=PENDING" forever	The array is waiting for a missing component. Run `mdadm --examine /dev/sdX` to find stale superblocks, then `mdadm --zero-superblock` on the wrong disk and reassemble.
Synology DSM shows rebuild stuck at 0%	SSH in, `cat /proc/mdstat` — if one disk shows as faulty but the GUI says healthy, force it out: `mdadm /dev/mdX --fail /dev/sdY` then `mdadm /dev/mdX --remove /dev/sdY`. Re-add the disk.
Hardware RAID (Dell PERC) rebuild stops at 99%	That's a metadata mismatch. Boot into the controller BIOS (Ctrl-R during POST), go to Virtual Disk Mgmt, and run "Consistency Check" — it fixes the parity mismatch without losing data.
Windows Storage Spaces parity rebuild stuck	Open PowerShell as admin, `Get-StorageJob` — if it shows "Repair" but progress is 0, run `Repair-VirtualDisk -FriendlyName "yourvdisk" -AsJob`. Sometimes a reboot is required because the virt disk is in a degraded state the UI doesn't show.

Prevention

Set TLER on every drive at install time. Run a weekly scrub—on mdadm, schedule echo 'check' > /sys/block/md0/md/sync_action via cron. On hardware, schedule consistency checks. Replace any drive that shows reallocated sectors (SMART attribute 5) above 10—that's a leading indicator of future stalls. Also, use disks from the same batch and firmware—mixing TLER behaviors causes timeouts. One more thing: if you're using SATA disks on a hardware RAID controller that expects SAS, you'll need to enable SCTERC explicitly; most LSI controllers default to 0 (disabled) for SATA, which causes exactly this stall.