根本原因是bitmap未启用或配置不当及speed_limit_min/max过于保守；需创建时启用internal bitmap并调高限速值至50MB/s以上，同时排查硬盘温度、RAID级别、I/O调度器和后台任务等瓶颈。
为什么 mdadm RAID 重建（rebuild）卡在几 MB/s？
根本原因通常是 bitmap 未启用或配置不当，导致整个阵列全盘校验；另外内核默认的 speed_limit_min 和 speed_limit_max 过于保守（常为 1000–2000 KB/s），尤其在 SSD 或 NVMe 背后的 RAID 中完全无法发挥硬件能力。
启用并调优 bitmap 是提速前提
bitmap 不是“可选优化”，而是 rebuild/reshape 场景下的必要机制——它记录哪些区域已同步，断电或中断后只需续跑未完成部分，而非重头扫全盘。
- 创建时启用：
mdadm --create /dev/md0 --bitmap=internal ...（internal最常用；external适合跨主机但需额外存储） - 已有阵列补加 bitmap（需先停止写入）：
mdadm --grow /dev/md0 --bitmap=internal - 检查是否生效：
cat /proc/mdstat输出中应含bitmap: internal - 注意：bitmap 本身有开销，小文件随机写密集场景可能略降性能；但对 rebuild 来说，利远大于弊
speed_limit_min 和 speed_limit_max 怎么设才有效？
这两个参数控制内核对 RAID 同步线程的带宽限制，单位是 KB/s，路径为 /sys/block/mdX/md/speed_limit_{min,max}。默认值往往严重低估现代磁盘吞吐能力。
- 查看当前值：
cat /sys/block/md0/md/speed_limit_min、cat /sys/block/md0/md/speed_limit_max - 临时提速（立即生效）：
echo 50000 > /sys/block/md0/md/speed_limit_min、echo 200000 > /sys/block/md0/md/speed_limit_max（即 50MB/s ~ 200MB/s） - 数值建议：从 50000（50MB/s）起步，观察
iostat -x 1中各成员盘的%util和await；若长期%utilawait await > 30ms 则说明已压满 I/O，应下调 - 永久生效需写入 udev 规则或 initramfs 钩子，单纯写进
/etc/sysctl.conf无效（该路径不归 sysctl 管理）
还有哪些容易被忽略的瓶颈？
即使 bitmap 和 speed_limit 都调好了，rebuild 仍慢，大概率是其他层压制了 I/O。
-
硬盘自身限速：某些 SATA SSD 在持续大块写入时会过热降频；用
smartctl -a /dev/sdX | grep Temperature查温度 - RAID 级别影响：RAID 5/6 rebuild 涉及读-计算-写三阶段，比 RAID 1 的镜像复制天然更慢；确认是否真有必要用 RAID 5/6 —— 多数新部署推荐 RAID 10 + 副本策略替代
- 系统 I/O 调度器：机械盘用
deadline，SSD 用none（或kyber）；cat /sys/block/sdX/queue/scheduler查看，echo none > /sys/block/sdX/queue/scheduler设置 - 后台任务干扰：
updatedb、logrotate、备份脚本等可能抢占 I/O；iotop -o可快速定位活跃进程
真正拖慢 rebuild 的，往往不是 mdadm 本身，而是没看清 I/O 栈哪一层在喘气。调参前先看 iostat -x 1 和 /proc/mdstat 的实时速率，比盲目改 speed_limit_max 到 1000000 更管用。
