我被分配了一个任务来测试和评估 Coffeelake 下硬件 RAID 的性能带有英特尔傲腾系统加速选项的英特尔 RST Premium在 RAID1 配置中 - 在 Linux 下。
我使用 Ubuntu 19.04，它dmraid默认安装（还尝试了其他几个需要额外安装的 Linux 版本dmraid）。我过去曾经使用过企业磁盘阵列，从用户的角度来看，我无法理解上面解释的 DUT 的价值。
安装后，系统正常启动，dmraid显示选项-s并-r报告良好/同步状态。我关机，移除其中一个磁盘（假设它发生故障），然后尝试仅使用一个磁盘启动。它无法启动，进入紧急 shell。
好的，我关闭电源并放回移除的磁盘。以我的企业理解，RAID 系统必须使用日志更新不同的信息，并且介质必须在此操作后同步。
但它没有发生。我看到后台正在重建 - 很可能是完全重建，dmsetup status达到最终值，然后什么都没有发生。它仍然显示 XXXX/XXXX，dmraid仍然显示nosync。没有看到磁盘活动。如果我关闭机器，然后再次启动，完全重建将从头开始，达到同一阶段，然后卡在那里。
我是 dmraid 的新手，尝试了一些 -R 选项，有时dmraid -s显示“不一致”或类似的信息，重建已再次开始，但停留在最终的 XXXX/XXXX 状态，卷仍然不一致。
进入机器的设置，删除 RAID 卷，重新创建它，但从逻辑上讲所有信息都丢失了（因此这不是从故障的 RAID 卷中恢复的方法）。
告诉我这里我哪些假设是错误的，以及为什么系统无法正确应对一个磁盘的缺失，当磁盘返回到集合中时变得非常疯狂。
我现在正在完全擦除其中一个磁盘，看看是否dmraid会自动找到并将其附加到磁盘组并执行重建，以使 RAID 卷准备就绪并同步。
更新：在完全擦除其中一个磁盘并将其安装到系统中后，BIOS/setup 显示该磁盘为非 RAID，原始磁盘为“已降级”，并显示“重建”选项。选择此选项后，setup 显示“正在重建”，但没有看到磁盘活动。然后我启动了 Ubuntu，它进入紧急 shell，似乎卷尚未准备好，并且显然正在后台执行重建 - 确认dmsetup status- 但我仍然无法正常使用系统。
重建完成后，卷状态仍然停留在不同步状态。init 5挂起，重新启动后 RAID 卷仍然不可用，并且新的重建已开始。
因此这种类型的“RAID”不能承受磁盘故障。
更新 1：该配置在 Windows 10 下完美运行。在系统关闭时从 R1 组中移除一个磁盘可使系统从另一个磁盘启动。Windows 具有 GUI 来检查状态并包括磁盘/启动重建。重建完成后，驱动程序将系统 RST 更新为正确状态，并且重建不会在下一个触发事件时错误地重新启动。R1 配置中的顺序读取性能为 1.1GB/s（使用 SATA3 磁盘）（Ubuntu 显示 528MB/s）。
答案1
原则上，您应该能够从不完整的 RAID 集启动（毕竟，如果磁盘在断电后没有旋转起来，您就必须这样做，这比磁盘在运行期间发生故障的可能性要大得多），但在默认设置下，由于某种原因，这似乎需要操作员许可（即强制组装阵列，然后继续启动）。
此外，原则上，仅仅尝试组装阵列但实际上并未组装阵列不应增加 RAID 超级块中的事件计数器，这是系统决定磁盘是否可以同步的方式。如果阵列组装时缺少磁盘，则该磁盘将丢失写入，因此当然需要重建，从而覆盖磁盘。
所以我怀疑阵列是在降级状态下组装的，但某些启动代码认为“降级”还不够好，并将您置于紧急 shell 中。此时已经做出了需要重建的决定。
重建应该最终让你处于一致的状态，但也许设备管理器需要一些命令来完成这里操作，就像 LVM 中的后台 pvmove 一样。
完全擦除的磁盘只有在被识别为热备用时才会被添加。在保守的设置中，我需要操作员采取行动将磁盘指定为热备用。如果有插槽，您可以在磁盘发生故障之前添加备用磁盘，这样可以在发生故障时立即切换，但我会谨慎地将故障后出现的第一个磁盘作为备用磁盘，至少不会询问操作员。
答案2
嵌入式英特尔 RAID 只不过是假冒：它所做的就是定义一个特定的元数据格式（Intel Matrix RAID）并提供一个小型可选 BIOS，以便从“RAID”设备而不是单个磁盘启动（从 BIOS 中看到）。
启动后，控制权将传递给 Linux 内核本身，有两种可能的方法：
- 分布式阵列或设备映射器 RAID，据我所知，它是一个已弃用RAID 实现；
- 姆拉伊德，或者经典的 Linux 软件 RAID，一种非常强大的 RAID 实现，是当前/推荐的实现。
简而言之：我真的会避免使用 dmraid。如果出于某些原因，您在使用 Intel fakeraid 时必须依赖 dmraid，我宁愿不是使用 fakeraid 本身（而是依赖于普通的 mdraid）。
对于你的启动问题，请查看这里：简而言之，由于特定的 dracut/systemd/mdraid 交互，移除好的磁盘并重新启动可能会导致降级的 RAID1 阵列“组装超时”。为避免这种情况，您需要以下之一：
- 在服务器启动并运行时移除磁盘（或声明其为故障）；
rd.retry通过将选项附加rd.retry=30到内核来降低启动时的超时时间；- 更新到不受影响的 dracut 版本。
答案3
如果重建完成后仍然报告状态为 nosync，请尝试：
# dmraid -a n
# dmraid -a y