我最近丢失了 RAID 阵列中的一个驱动器（系统发出了一封电子邮件警告我，这真是太好了），经过一些驱动器重组和更换新驱动器后，我一切都安全了。但在此过程中，我发现此主题，这让我开始思考如何实际测试磁盘错误和其他不良事件，而无需实际发生。当我运行建议的 tar 命令时：
tar c /my/raid/device/mount/point > /dev/null
它在几秒钟内就完成了，这显然不足以让系统真正读取所有文件（远远超过 1 TiB）——所以我想我的第一个问题是为什么这可能不起作用。如果我做这样的事情：
find . -type f | xargs md5sum
该命令运行得很好，而且需要很长时间才能完成……但它也会在执行所有求和时占用大量 CPU。这可能比“tar”更快或更容易，也可能不是——我更好奇为什么 tar 命令没有像我预期的那样工作。
无论如何 - 第二个问题，更普遍的是：有没有办法按照这样的思路进行故障注入测试：
- 找到（或创建）一个我不关心的文件......
- 确定磁盘上的某个块用于存储这个特定的文件......
- 欺骗软件/操作系统，让其认为这个块是“坏的”（我假设通过某种方式标记它，这是我的知识用尽的地方）
- 运行我的测试脚本和/或错误检查例程
- 确认阵列报告错误并执行其他必要的纠正措施...
- 将该块/扇区再次标记为“好”，以便系统/操作系统正常使用它。
这似乎是可行的，但是我对 Linux 工具的了解不够详细，无法让我在设备级别将某个块标记为坏块，而实际上它并不是一个坏块......
对此有什么想法？或者，如果有更优雅的方式来解决这个问题，我也很高兴听到这个消息......
答案1
Linux 中有很多有用的故障注入基础设施。其中一个可能对你的测试工作有帮助。
本演示文稿的第 7 页展示了使用 伪造块设备问题的示例dmsetup。
https://mbroz.fedorapeople.org/talks/DeviceMapperBasics/dm.pdf
医学博士(4)本身有一个模式FAULTY，您可以使用它来模拟读/写错误。
故障
FAULTY md 模块用于测试目的。故障阵列只有一个组件设备，并且通常在没有超级块的情况下组装，因此创建的 md 阵列可直接访问组件设备中的所有数据。
FAULTY 模块可用于模拟故障，以便测试其他 md 级别或文件系统。故障可选择在读取请求或写入请求时触发，可以是瞬态的（后续对该地址的读取/写入可能会成功）或持久的（后续对同一地址的读取/写入将失败）。此外，读取故障可以是“可修复的”，这意味着它们会一直存在，直到在同一地址发出写入请求。
故障类型可以用一个周期来请求。在这种情况下，故障将在给定数量的相关类型的请求后重复出现。例如，如果持久读取故障的周期为 100，则每 100 次读取请求都会生成一个故障，并且会记录故障扇区，以便对该扇区的后续读取也会失败。
被记住的故障扇区数量是有限制的。超过此限制后产生的故障将被视为暂时故障。
可以刷新故障扇区列表，并清除故障模式的活动列表。
控制它的选项列在mdadm(8)在下面-p, --layout=。
设置faulty级别的故障模式时，选项有：write-transient、wt、read-transient、rt、write-persistent、wp、read-persistent、rp、write-all、read-fixable、rf、clear、flush、none。
每个故障模式后面可以跟一个数字，用作故障生成之间的时间间隔。如果没有数字，则故障会在第一次相关请求时生成一次。如果有数字，则故障会在多次请求之后生成，并且每次时间间隔过去后都会继续生成。
通过使用 --grow 选项设置后续故障模式，可以同时使多种故障模式变为当前状态。
“clear”或“none”将删除任何待处理或周期性故障模式，而“flush”将清除任何持续性故障。
linux-raid以下是邮件列表存档中的示例错误注入这也应该有助于您开始使用 md 故障注入选项。=)
答案2
对于你的第一个问题：
tar c /my/raid/device/mount/point > /dev/null
这将取决于您的发行版的 tar 在没有“f”参数的情况下的行为。我在 Debian (wheezy) 系统上尝试过，它的行为与您预期的一样 - 存档被写入 stdout。但是在 FreeBSD 系统上。它返回一个错误：
tar: Failed to open '/dev/sa0'
更通用的方法是明确指定 stdout 作为档案：
tar cf - /my/raid/device/mount/point > /dev/null
编辑：哎呀！或者干脆忘掉重定向：
tar cf /dev/null /my/raid/device/mount/point
除了 Kassandry 的出色的答案，如果您的物理驱动器支持预测故障，我还建议您使用 SMART。
答案3
Tar 有一个“优化”，如果输出是 /dev/null，它几乎不执行任何操作
无论如何，你可以尝试这个来欺骗它完成工作：
tar c /my/raid/device/mount/point | cat > /dev/null