Ubuntu 18.04 下使用 mdadm 构建高可用软件 RAID5 实战指南

1. 项目概述：为什么在 Ubuntu 18.04 上亲手搭 RAID 不是“复古操作”，而是运维基本功

你手头有四块全新的 4TB SATA 硬盘，刚装好 Ubuntu 18.04 Server，准备部署一个内部文件归档系统。这时候有人建议：“直接用 LVM 吧，简单”；也有人说：“买个硬件 RAID 卡，稳当”。但如果你真这么做了，大概率会在三个月后某个凌晨三点被报警邮件叫醒——因为 LVM 没冗余，单盘故障即全盘皆墨；而硬件 RAID 卡一旦损坏，换卡重载配置时发现固件版本不兼容，重建阵列失败，数据永久丢失。这不是危言耸听，我去年在给一家本地律所做服务器迁移时就撞上过一模一样的场景：Dell R720 上的 PERC H710 卡突然报错，BIOS 里进不去 RAID 配置界面，最后靠 mdadm 从零重建了整个 /home 分区的 RAID5，才把三年的案件扫描件救回来。

这就是为什么标题里这个看似“老掉牙”的操作—— How To Create RAID Arrays with mdadm on Ubuntu 18.04 ——至今仍是 Linux 运维人必须刻进肌肉记忆里的技能。它不是教你怎么装软件，而是教你构建一种 可审计、可迁移、可降级、可裸机恢复 的数据韧性架构。 mdadm 不是替代硬件 RAID 的“穷人的方案”，它是把 RAID 控制逻辑从黑盒芯片里解放出来，交还给操作系统内核和管理员大脑的主动权。你不需要记住 Dell、华为、浪潮、超聚变各家服务器 BIOS 里 RAID 设置的按键组合（F10？Ctrl+R？Del 进去再选 Advanced？），也不用担心某天更换主板后 RAID 元数据无法识别——因为 mdadm 的元数据是写在磁盘开头的标准化结构，只要 Linux 内核能认出这块盘，就能 mdadm --assemble 把阵列原样拼回来。

关键词 mdadm 、 Ubuntu 18.04 、 software RAID 组合在一起，指向的是一套成熟、稳定、文档完备、社区支持极强的技术栈。Ubuntu 18.04 是 LTS 版本，内核为 4.15，对 mdadm 4.0+ 的支持已非常完善，不存在驱动缺失或模块加载失败的问题。而所谓“raid磁盘挂载到其他目录”，本质是 Linux 文件系统挂载机制与 RAID 设备节点的衔接问题，不是 RAID 本身的功能缺陷；至于“曙光服务器做raid”“中兴服务器做磁盘如何做raid”，这些厂商定制化 BIOS 的差异，恰恰反向证明了 mdadm 的普适价值——它绕开了所有厂商私有 BIOS 层，直击存储抽象层。你不需要懂华为什么叫 iBMC、浪潮怎么进 F11，你只需要会 lsblk 、 fdisk -l 、 mdadm --create 这三步，就能在任何 x86_64 服务器上完成 RAID 构建。这才是真正的“一次学习，处处可用”。

2. 核心设计思路与方案选型：为什么不用硬件 RAID？为什么选 RAID5 而非 RAID10？为什么是 mdadm 而非 lvmraid？

2.1 硬件 RAID 的三大隐性成本，远超采购价本身

很多人一提 RAID 就默认“得配 RAID 卡”，这其实是被厂商营销长期塑造的认知惯性。我在给某高校数据中心做存储评估时，曾对比过两套方案：一套是 Dell R730 + PERC H730P（带缓存+电池）硬件 RAID，另一套是同款服务器 + 四块企业级 SSD + mdadm 软件 RAID。表面看，硬件方案贵 2800 元，但真实成本远不止于此：

• 故障定位成本 ：硬件 RAID 卡故障时， dmesg 只显示“md: kicking non-fatal device”，根本看不出是卡坏了还是线松了。而 mdadm 出问题， /proc/mdstat 和 mdadm --detail /dev/md0 输出全是明文状态，连哪块盘 SMART 温度超标都一目了然。
• 固件锁定成本 ：H730P 卡升级固件需进 Lifecycle Controller，而某次升级后，RAID5 阵列在重启时无法自动挂载，日志里只有一行 md: md0 stopped 。查了三天才发现是固件 Bug，必须回滚到旧版，但旧版又不支持新硬盘型号。 mdadm 没有固件，只有内核模块，升级内核即可平滑过渡。
• 灾备恢复成本 ：去年帮一家制造企业恢复一台报废的 Lenovo ThinkServer RD540，原 RAID 卡已损毁。我们用一台二手 NUC 安装 Ubuntu 18.04，插上原服务器的四块盘，执行 mdadm --assemble --scan ，12 秒后 /dev/md0 就出现在 lsblk 里——因为 mdadm 元数据是标准格式，不依赖特定控制器。

提示：硬件 RAID 并非一无是处。对于 Oracle RAC、SQL Server 等要求亚毫秒级 I/O 延迟的 OLTP 场景，带 BBU 的硬件 RAID 卡的写缓存确实有优势。但对绝大多数文件服务、虚拟机宿主、备份归档等场景， mdadm 的性能损耗几乎不可测，而可靠性与可控性则大幅提升。

2.2 RAID 级别选择：RAID5 是 Ubuntu 18.04 下四盘环境的理性平衡点

面对四块 4TB 硬盘，常见选项有 RAID0、RAID1、RAID5、RAID6、RAID10。我们逐个拆解其在 Ubuntu 18.04 实际环境中的表现：

• RAID0（条带） ：容量 = 16TB，读写速度翻倍，但 零容错 。一块盘坏，全部数据完蛋。我见过太多用户因贪图空间和速度选 RAID0，结果在 apt upgrade 过程中遭遇磁盘掉线， /usr 分区瞬间只读，系统彻底瘫痪。这不是理论风险，是高频事故。
• RAID1（镜像） ：仅用两块盘，容量 = 4TB，写入性能下降约 15%，但读取可并行。适合系统盘，不适合数据盘——你花了四块盘的钱，只得到一块盘的容量。
• RAID10（镜像+条带） ：需偶数盘，最小 4 盘。容量 = 8TB，可容忍任意一块盘故障，甚至同一镜像组两块盘同时故障（概率极低）。但它的写入放大系数为 2.0，意味着每写 1MB 数据，实际要往磁盘发 2MB IO。在 Ubuntu 18.04 默认 ext4 文件系统下，小文件随机写性能会明显低于 RAID5。
• RAID5（分布式奇偶校验） ：容量 = 12TB（4×4TB−4TB），可容忍 任意一块盘故障 ，写入放大系数约 1.33（一次写需更新数据块+校验块）。这是关键：RAID5 在容量利用率、容错能力、随机写性能三者间取得了最佳平衡。实测在 Ubuntu 18.04 + ext4 + ionice -c 2 -n 7 调度下，4K 随机写 IOPS 稳定在 320 左右，完全满足 NFS 文件共享和轻量级数据库需求。
• RAID6（双奇偶校验） ：容量 = 8TB（4×4TB−2×4TB），可容忍两块盘同时故障。但计算开销大，尤其在 18.04 内核 4.15 下， md 子系统对 RAID6 的 SIMD 优化尚未完全成熟，连续写吞吐比 RAID5 低 18%。除非你管理的是 PB 级医疗影像库且预算允许停机 3 天重建，否则 RAID6 是过度设计。

所以，当标题明确指向 Ubuntu 18.04 且未限定盘数时， RAID5 是默认推荐方案 ——它不是技术最优，而是工程最优：用最低的学习成本、最少的硬件投入、最短的重建时间（实测 4TB 盘 RAID5 重建约 9.2 小时），换取可接受的可靠性。

2.3 mdadm vs 其他工具：为什么不用 lvmraid 或 btrfs raid？

Ubuntu 18.04 生态中有多个“软 RAID”选项，但 mdadm 是唯一经过十年以上生产环境验证的通用方案：

• lvmraid ：LVM2 从 2.02.111 版本起支持 lvconvert --type raid5 ，但它本质是 LVM 对 md 的封装。问题在于：LVM 的元数据管理更复杂， vgscan 失败会导致整个卷组不可见；且 lvmraid 的监控告警机制远不如 mdadm 成熟。我试过在测试机上用 lvmraid 创建 RAID5，结果 lvchange -an 后无法 lvchange -ay ， dmesg 显示 device-mapper: raid: Failed to load target ，最终还是得靠 mdadm --zero-superblock 清理底层设备才能恢复。
• btrfs raid ：btrfs 文件系统内置 RAID 功能，语法简洁如 mkfs.btrfs -d raid5 -m raid5 /dev/sdb /dev/sdc /dev/sdd /dev/sde 。但它把文件系统层和 RAID 层耦合过紧。一旦 btrfs 自身出现 bug（18.04 的 btrfs-progs 4.15 版本曾有元数据泄漏问题），整个 RAID 结构可能无法挂载。而 mdadm + ext4 是清晰的分层：RAID 层只管块设备聚合，文件系统层只管数据组织，任一层出问题都不影响另一层恢复。
• zfs on linux ：ZFS 确实强大，但 Ubuntu 18.04 官方仓库中 ZFS 支持仍属“unsupported”，需手动编译 DKMS 模块，内核升级后极易失效。我曾为某客户部署 ZFS RAIDZ2，结果一次 apt upgrade 后 ZFS 模块未重新编译，服务器重启直接卡在 initramfs。 mdadm 是内核主线模块，随系统更新自动适配，零维护负担。

注意： mdadm 的核心优势在于“存在即稳定”。它不追求炫技，只确保一件事：当你执行 mdadm --create /dev/md0 --level=5 --raid-devices=4 /dev/sdb /dev/sdc /dev/sdd /dev/sde 时，它会老老实实按 POSIX 标准写入 superblock，生成 /dev/md0 设备节点，并在 /proc/mdstat 中持续报告状态。这种确定性，是任何新兴存储方案都无法替代的基础设施价值。

3. 核心细节解析与实操要点：从磁盘识别到元数据写入的每一处陷阱

3.1 磁盘识别阶段：为什么 lsblk 比 fdisk -l 更可靠？如何识别“假盘”？

在 Ubuntu 18.04 中，正确识别物理磁盘是 RAID 构建的第一道生死线。新手常犯的错误是直接 fdisk -l ，看到 /dev/sdb /dev/sdc 就开始操作，结果发现其中一块是 USB 3.0 读卡器挂载的 SD 卡，或者某块盘被 BIOS RAID 模式（Intel RST）劫持， /dev/sdb 实际是 nvme0n1p1 的别名。

正确流程必须是三步交叉验证：

1. lsblk -S 查 SCSI 设备拓扑
   执行 sudo lsblk -S ，输出类似：

   NAME HCTL       TYPE VENDOR   MODEL             REV TRAN
   sda  2:0:0:0    disk ATA      WDC WD40EFRX-68W 1R01 sata
   sdb  3:0:0:0    disk ATA      ST4000NM0035-1V4 0002 sata
   sdc  4:0:0:0    disk ATA      ST4000NM0035-1V4 0002 sata
   sdd  5:0:0:0    disk ATA      ST4000NM0035-1V4 0002 sata
   sde  6:0:0:0    disk ATA      ST4000NM0035-1V4 0002 sata
   

   关键看 HCTL （Host:Channel:Target:Lun）字段。真实 SATA 盘的 HCTL 应为连续整数（如 2:0:0:0, 3:0:0:0），且 TRAN 列为 sata 。若某盘 TRAN 是 usb ，立刻排除；若 HCTL 中 Channel 或 Target 出现非零值（如 0:1:0:0），说明它可能处于 BIOS RAID 模式，需进 BIOS 关闭 Intel RST 或 AMD fTPM。

2. smartctl -i /dev/sdX 验证物理属性
   对每块候选盘执行 sudo smartctl -i /dev/sdb ，重点检查：

   • User Capacity ：确认是否为 4TB（4000787030016 bytes）
   • Rotation Rate ：应为 7200 rpm （企业级盘），若显示 Solid State Device 则是 SSD，需调整 --bitmap 参数
   • ATA Version ：应为 ACS-3 T13/2161-D revision 3b 或更高，避免使用老旧 ATA-6 盘

3. cat /sys/block/sdX/device/model 直读设备模型
   执行 sudo cat /sys/block/sdb/device/model ，输出应为 ST4000NM0035-1V4 这类标准型号。若输出为空或乱码，说明该设备被 udev 规则重命名（如 by-id 链接），此时必须用 ls -l /dev/disk/by-path/ 查找原始路径，例如：

   pci-0000:00:1f.2-ata-1 → ../../sdb
   pci-0000:00:1f.2-ata-2 → ../../sdc
   

   这样能确保你操作的是物理连接路径，而非易变的 /dev/sdX 名称。

实操心得：我曾在一台超聚变服务器上遇到诡异问题—— lsblk 显示四块盘，但 mdadm --create 总提示“device busy”。最后发现是 BIOS 中启用了“SATA Controller Mode: RAID”，导致 Linux 内核加载了 ahci 模块，但磁盘被主板 RAID 控制器虚拟化。解决方案是进 BIOS 将 SATA 模式改为 AHCI ，保存重启后 lsblk 才显示真实设备。这个细节在“超聚变服务器做raid”“华为服务器icmb下如何做raid”的搜索结果中极少被提及，却是实际部署的首要关卡。

3.2 磁盘预处理： wipefs 和 mdadm --zero-superblock 的本质区别

很多教程直接让新手 dd if=/dev/zero of=/dev/sdb bs=1M count=100 清空磁盘前 100MB，这是严重错误。 dd 会破坏分区表，但 mdadm 的 superblock 可能写在磁盘末尾（如 1.2 版本 superblock 在最后 128KB）， dd 无法覆盖。

正确预处理必须分两步：

1. sudo wipefs -a /dev/sdX 彻底擦除所有文件系统签名
   wipefs 是 util-linux 工具，能识别并删除 ext4、xfs、ntfs、lvm2、mdraid 等所有已知元数据签名。执行后输出：

   /dev/sdb: 8 bytes were erased at offset 0x00000200 (ext2): 53 65 72 69 61 6c 20 31
   /dev/sdb: 8 bytes were erased at offset 0x00001000 (md): 52 41 49 44 20 64 65 76
   

   这表示它清除了 ext2 的序列号和 mdadm 的 "RAID dev" 签名。注意 -a 参数是关键，它会遍历整个磁盘查找签名，而非只清开头。

2. sudo mdadm --zero-superblock /dev/sdX 专清 RAID 元数据
   即使 wipefs 清除了大部分签名， mdadm 的 superblock 可能残留。此命令会精准定位并覆写 superblock 区域（通常在开头 4KB 和结尾 4KB）。执行后无输出即成功。若提示 No super block found ，说明该盘确实干净。

注意：这两步顺序不能颠倒。先 mdadm --zero-superblock 再 wipefs 是安全的；但若先 wipefs 后 mdadm --zero-superblock ，后者可能因找不到 superblock 而静默失败，导致后续 mdadm --create 时检测到旧元数据而拒绝创建。

3.3 创建阵列的核心参数： --metadata 、 --chunk 、 --bitmap 如何影响重建速度与稳定性

mdadm --create 命令中，以下三个参数直接决定 RAID5 的长期可用性：

• --metadata=1.2 ：指定 superblock 版本。Ubuntu 18.04 默认使用 1.2 版本，它将 superblock 存储在设备开头 4KB 处（而非旧版 0.90 的末尾），便于 GRUB2 引导。若误用 --metadata=0.90 ， update-grub 会报错 failed to get canonical path of /dev/md0 ，导致系统无法从 RAID 启动。

• --chunk=512K ：条带单元大小。这是影响性能的关键。计算公式为： chunk_size = (disk_count - 1) × page_size 。Ubuntu 18.04 默认 page_size 为 4KB，故 (4-1)×4KB = 12KB ，但这是理论最小值。实测表明，对于 4TB 企业级盘， 512K 是最佳平衡点：

  • 过小（如 64K）：校验计算频繁，CPU 开销大，重建时 CPU 占用率达 95%
  • 过大（如 2M）：小文件写入需读取整个 chunk 更新校验，IOPS 下降 40%
  • 512K ：在 bonnie++ 测试中，4K 随机写 IOPS 达 320，1M 连续写吞吐达 480MB/s，且重建 CPU 占用稳定在 65%

• --bitmap=internal ：启用内部位图。这是 RAID5 的“生命线”。没有位图时，每次系统异常断电后重启， md 子系统会强制执行全盘一致性检查（resync），耗时数小时。而 --bitmap=internal 会在 superblock 附近分配一小块区域（约 4MB），记录哪些 chunk 已同步。实测显示，意外断电后重启， /proc/mdstat 显示 recovery = 0.2% ，15 分钟内完成增量恢复，而非 8 小时全盘扫描。

完整创建命令应为：

sudo mdadm --create --verbose /dev/md0 \
  --level=5 \
  --metadata=1.2 \
  --chunk=512K \
  --bitmap=internal \
  --raid-devices=4 \
  /dev/sdb /dev/sdc /dev/sdd /dev/sde

实操心得：我在浪潮服务器上部署时，因未加 --bitmap=internal ，一次机房空调故障导致服务器断电，重启后 RAID5 进入 11 小时 resync，期间所有 NFS 客户端超时。此后所有生产环境 RAID5 必加此参数。它不增加硬件成本，却将灾难恢复时间从小时级压缩到分钟级。

4. 实操过程与核心环节实现：从创建、格式化到持久化挂载的完整链路

4.1 创建阵列并监控状态： /proc/mdstat 是你的实时仪表盘

执行创建命令后，不要急于格式化。先用 watch -n 1 cat /proc/mdstat 实时观察阵列初始化过程。正常输出如下：

Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sde[4] sdd[3] sdc[2] sdb[1]
      11720110080 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UUU_]
      bitmap: 1/88 pages [4KB], 65536KB chunk

逐字段解读：

• [4/3] ：4 块盘参与，当前 3 块在线（ _ 表示缺失盘）
• [UUU_] ：U=Up，表示前三块盘正常，第四块（sde）正在同步
• bitmap: 1/88 pages ：位图已分配 1 页（4KB），共 88 页
• algorithm 2 ：RAID5 使用左对称算法（left-symmetric），这是 18.04 默认，兼容性最好

同步过程中， blocks 字段会缓慢增长， [UUU_] 会逐步变为 [UUUU] 。此时可执行 sudo mdadm --detail /dev/md0 查看详细信息：

sudo mdadm --detail /dev/md0
# 输出关键行：
#        Array Size : 11720110080 (11177.15 GiB 12000.00 GB)
#     Used Dev Size : 3906703360 (3725.72 GiB 4000.00 GB)
#       Raid Level : raid5
#      Chunk Size : 512K
#     Bitmap : internal
#     State : clean, degraded, recovering
#     Active Devices : 4
#     Working Devices : 4
#     Failed Devices : 0
#     Spare Devices : 0

注意 State 字段： clean, degraded, recovering 表示正常重建中；若出现 active, FAILED ，则立即停止操作，用 smartctl -a /dev/sdX 检查对应盘健康状态。

提示：重建速度受磁盘性能和系统负载影响。实测在 Ubuntu 18.04 + 4TB 7200rpm 盘上，平均重建速率为 45MB/s。可通过 echo 100000 > /proc/sys/dev/raid/speed_limit_min 提升最小速度阈值（单位 KB/s），但会增加磁盘负载，建议仅在业务低峰期操作。

4.2 格式化与文件系统选择：为什么 ext4 是 Ubuntu 18.04 的最优解？

阵列同步完成后（ /proc/mdstat 显示 State : clean ），执行格式化：

sudo mkfs.ext4 -b 4096 -E stride=128,stripe-width=384 /dev/md0

参数详解：

• -b 4096 ：块大小设为 4KB，匹配 x86_64 页大小，减少内存碎片
• -E stride=128,stripe-width=384 ：这是 ext4 针对 RAID5 的关键优化。 stride 指一个 RAID 条带包含多少文件系统块， stripe-width 指一个 RAID 条带跨越多少文件系统块。计算公式：
  • stride = chunk_size / block_size = 512KB / 4KB = 128
  • stripe-width = stride × (disk_count - 1) = 128 × 3 = 384 此设置让 ext4 的 inode 分配器知道 RAID5 的物理布局，避免跨条带写入，提升顺序读写性能约 22%。

格式化完成后，创建挂载点并挂载：

sudo mkdir -p /data/archive
sudo mount /dev/md0 /data/archive

验证挂载：

df -h /data/archive
# 输出应为：
# /dev/md0       10T   89G   10T   1% /data/archive

4.3 持久化配置： /etc/mdadm/mdadm.conf 的正确写法与陷阱

若不配置持久化，服务器重启后 /dev/md0 将消失，需手动 mdadm --assemble 。正确做法是生成配置文件：

1. 生成初始配置

   sudo mdadm --detail --scan >> /etc/mdadm/mdadm.conf
   

   此命令会追加一行类似：

   ARRAY /dev/md0 metadata=1.2 name=ubuntu:0 UUID=1a2b3c4d:5e6f7g8h:9i0j1k2l:3m4n5o6p
   

2. 手动修正配置 （关键！）
   许多教程忽略此步，导致 initramfs 无法识别阵列。打开 /etc/mdadm/mdadm.conf ，确保：

   • 删除所有 DEVICE 行（如 DEVICE /dev/sdb /dev/sdc... ），因为设备名可能变化
   • 保留且仅保留 ARRAY 行
   • 在文件开头添加 AUTO +1.2 ，指定自动扫描 superblock 版本：

     AUTO +1.2
     ARRAY /dev/md0 metadata=1.2 name=ubuntu:0 UUID=1a2b3c4d:5e6f7g8h:9i0j1k2l:3m4n5o6p
     

3. 更新 initramfs

   sudo update-initramfs -u
   

   此命令将 mdadm 模块和 /etc/mdadm/mdadm.conf 打包进 initramfs。若跳过此步，重启后系统卡在 dracut 阶段，提示 Waiting for /dev/md0 .

4. 验证持久化
   重启前执行：

   sudo mdadm --stop /dev/md0
   sudo mdadm --assemble --scan
   mount | grep md0
   

   若能成功挂载，说明配置正确。

注意： /etc/mdadm/mdadm.conf 中的 UUID 是 mdadm 生成的，不是磁盘的 PARTUUID 。它由 mdadm --examine /dev/sdb 输出的 Array UUID 字段决定，全局唯一，不会因磁盘顺序改变而失效。这是 mdadm 比硬件 RAID 更可靠的底层设计。

4.4 挂载到自定义目录： /etc/fstab 的安全写法与 nofail 选项

将 RAID 设备挂载到 /data/archive 这类非根目录，需在 /etc/fstab 中添加条目：

/dev/md0    /data/archive    ext4    defaults,nofail,x-systemd.device-timeout=30    0 2

参数说明：

• defaults ：启用 rw,suid,dev,exec,auto,nouser,async
• nofail ： 最关键参数 。若阵列因某盘故障无法启动，系统不会卡在 Failed to mount /data/archive ，而是继续启动，仅记录警告。没有它，单盘故障可能导致整个服务器无法进入 multi-user.target。
• x-systemd.device-timeout=30 ：systemd 等待设备超时时间设为 30 秒，避免无限等待
• 0 2 ：不备份（dump），启动时 fsck 顺序为 2（根目录为 1）

添加后执行 sudo systemctl daemon-reload && sudo mount -a 测试。若报错 mount: /data/archive: wrong fs type ，说明 /dev/md0 未激活，需先 mdadm --assemble --scan 。

实操心得：“raid磁盘挂载到其他目录”是高频搜索词，但多数答案只教 fstab 语法，忽略 nofail 。我在某次为客户部署时，因未加 nofail ，RAID5 中一块盘 SMART 报警但未掉线， mount -a 卡住 90 秒，systemd 超时后进入 emergency mode。加上 nofail 后，即使盘已离线，系统也能正常启动，管理员可从容登录后处理。

5. 常见问题与排查技巧实录：从“Device or resource busy”到“Cannot open /dev/md0”

5.1 典型问题速查表

5.2 “曙光服务器做raid”“华为服务器做raid”等厂商特有问题的通用解法

搜索热词中大量出现各品牌服务器名称，本质是用户被厂商 BIOS/UEFI 的 RAID 设置界面困住了。但 mdadm 的哲学是： 绕过 BIOS，直面硬件 。以下是通用解法：

• 曙光 I620-G30 ：默认启用“SAS RAID Mode”，需进 BIOS → Advanced → SAS Configuration → SAS Controller Mode → 改为 HBA Mode 。否则 lsblk 只显示 cciss!c0d0 ， mdadm 无法识别物理盘。
• 华为 RH2288H V3 ：iBMC 界面中“Storage”→“RAID Configuration”默认为“Enabled”，需改为 Disabled ，并确保“SATA Controller”设为 AHCI 。否则内核加载 mpt3sas 模块， /dev/sdX 被映射为 mpt3sas0 设备。
• 浪潮 NF5280M5 ：BIOS 中“Advanced”→“SATA Configuration”→“SATA Mode Selection”需设为 AHCI ，而非 RAID 或 IDE 。 RAID 模式下， mdadm 会看到 nvme0n1 但看不到 SATA 盘。
• Dell R720 ：Lifecycle Controller 中“Storage”→“Controller Management”→“Controller Properties”→“RAID Policy”需设为 Non-RAID 。否则 PERC 卡会拦截所有 SATA 请求。

统一验证方法：重启后，在 GRUB 菜单按 e 编辑启动项，在 linux 行末尾添加 rd.md=0 rd.lvm=0 ，然后 Ctrl+X 启动。若此时 lsblk 能列出所有物理盘，则 BIOS 设置正确。

5.3 RAID 状态监控与预警：用 cron + mail 实现无人值守

生产环境必须建立监控。在 Ubuntu 18.04 中，最简方案是每日检查 /proc/mdstat ：

# 编辑 root crontab
sudo crontab -e
# 添加：
0 2 * * * /bin/bash -c 'if ! grep -q "\[UUU\]" /proc/mdstat; then echo "RAID WARNING: $(date)" | mail -s "RAID Alert on $(hostname)" admin@example.com; fi'

更专业的方案是使用 mdadm --monitor ：

sudo mdadm --monitor --mail=admin@example.com --delay=1800 /