mdadm 创建 raid 1 时 /dev/sdb1 和 /dev/sdc1 不能直接用，因需分区表干净、无文件系统、未挂载且非 lvm pv；raid 5 重建显示 0.1% 实为一致性校验，属正常；mdadm.conf 中 uuid 比设备名更可靠；raid 10 默认 near 布局最优；元数据版本与启动设备发现顺序是关键易忽略点。
mdadm 创建 RAID 1 时为什么 /dev/sdb1 和 /dev/sdc1 不能直接用？
因为 mdadm 要求参与 RAID 的分区必须有干净的分区表、无文件系统、且未被挂载或用作 LVM PV。常见错误是直接拿已有数据的分区去建阵列，结果报错 Device or resource busy 或 Invalid argument。
- 先确认状态：
lsblk和cat /proc/mdstat看是否已有活动阵列 - 清空旧签名：
sudo wipefs -a /dev/sdb1 /dev/sdc1（比dd if=/dev/zero更安全） - 禁用可能干扰的自动服务：
sudo systemctl stop lvm2-lvmetad（尤其在 CentOS/RHEL 上） - 确保没挂载：
sudo umount /dev/sdb1，并检查/etc/fstab是否残留条目
RAID 5 重建失败卡在 0.1% 怎么办？
这不是卡住，而是内核在做一致性校验（check），默认策略会扫描全盘。实际进度不显示，但 I/O 活跃、mdstat 显示 checking 就是正常行为。强行中断反而可能损坏元数据。
- 查看真实状态：
watch -n1 'cat /proc/mdstat'，关注recovery或check字样 - 调快重建速度（仅限临时）：
echo 50000 > /proc/sys/dev/raid/speed_limit_min（单位 KB/s） - 避免同时写入：重建中尽量别跑
rsync或数据库导入，否则触发“写入暂停重建”逻辑 - 如果真卡死（
iostat -x 1显示零 I/O 持续超 10 分钟），可能是某块盘响应异常，用smartctl -a /dev/sdX查坏道
mdadm.conf 里 ARRAY 行的 UUID 和设备名哪个更可靠？
UUID 更可靠。/dev/sdX 名称在热插拔、多控制器或 BIOS 启动顺序变化时极易漂移，而 mdadm --detail --scan 输出的 UUID 是阵列元数据固化的标识，内核靠它识别和组装。
- 生成配置前务必运行：
sudo mdadm --detail --scan >> /etc/mdadm.conf - 不要手动写
ARRAY /dev/md0 devices=/dev/sdb1,/dev/sdc1—— 这种写法在重启后大概率失效 - Debian/Ubuntu 需额外确认：
INITRDSTART="all"在/etc/initramfs-tools/conf.d/mdadm中，否则 initramfs 不加载 RAID - 更新配置后必须刷新 initramfs：
sudo update-initramfs -u（Debian系）或sudo dracut -f（RHEL系）
RAID 10 用 near/ far/ offset 模式，选哪个？
绝大多数场景直接用默认 near（等同于 mdadm --create ... --layout=near）。它把相同数据块镜像到不同磁盘，读性能好、故障恢复快；far 和 offset 主要为老式机械盘顺序读优化，现代 SSD 或 NVMe 上反而降低随机读效率。
- 创建命令示例：
sudo mdadm --create /dev/md0 --level=10 --raid-devices=4 /dev/sdb /dev/sdc /dev/sdd /dev/sde（自动 near） -
far会导致单次 read 请求跨多个磁盘寻道，在高并发小 IO 下延迟翻倍 - 只有当你的 workload 是持续大块顺序读（如视频流服务器）、且用的是 7200rpm 以下机械盘时，才考虑
--layout=far - 验证布局：
sudo mdadm --detail /dev/md0 | grep Layout，输出应为Layout : near=2
--metadata=1.2 vs 0.90）和启动时设备发现顺序，这两个点最容易被跳过，但一旦出问题，系统根本进不了 initramfs。
