md-raid-deadlock-recovery

To fix an mdadm RAID5 deadlock where system IO hangs despite healthy SMART statuses, diagnose the kernel lock pattern showing raid5_get_active_stripe contention and execute a safe reboot workflow with recovery hardening. This resolves frozen sync_action and stalled container writes.

mdcheck freezes and blocks processes due to raid5_get_active_stripe stripe-cache lock contention in the kernel. When sync_action is frozen and sync speed drops to near-zero, fsync operations and container writes stall indefinitely until a system reboot.

To safely reboot during a production RAID deadlock, run pre-reboot hardening scripts to disable mdcheck timers and mdadm autocheck, tune root fsck mount-count when safe, validate Cloudflare Tunnel SSH access, and verify container restart policies before initiating the reboot.

After rebooting to recover from a RAID5 deadlock, run a post-reboot verification pass to confirm RAID sync_action returns to idle, validate /data writeability, check container health, and perform optional HTTP health checks to ensure critical service reachability.

Recovering from a RAID6 stripe-cache deadlock requires a system reboot, but you can minimize container workload disruption by assessing and verifying container restart policies beforehand. This ensures services come back automatically post-reboot.

Yes, mdadm autocheck and mdcheck timers must be disabled before rebooting a frozen RAID array. This prevents the stripe-cache deadlock condition from immediately re-triggering upon boot, allowing the array to return to a clean idle state.