最近我在RAIDarrays中失去了一个驱动器（从系统收到一封电子邮件，告诉我这是非常好的），经过一些驱动器的洗牌和换入新驱动器，我都安全可靠。 但一路上，我发现这个线程 ，这让我想到如何实际testing磁盘错误和其他坏事情，而没有他们真正发生。 当我运行build议的tar命令时：
tar c /my/raid/device/mount/point > /dev/null 它在几秒钟内完成，这显然不足以让系统实际读取所有文件（远远超过TiB） – 所以我想我的第一个问题是为什么这可能不起作用。 如果我做这样的事情：
find . -type f | xargs md5sum
该命令运行得很好，需要很长时间才能完成…但是它也会加载CPU进行所有的求和。 这可能也可能不是比“焦油”更快或更容易 – 我更加好奇，为什么tar命令没有按预期工作。
无论如何 – 第二个问题，更一般地说：是否有办法按照这些方法做一些事情来进行故障注入testing：
这似乎是可行的，但我没有足够的Linux工具的详细知识，这将允许我标记一个块在设备级别不好，实际上是一个坏块…
这个想法？ 或者，如果有更好的方法来解决这个问题，我很高兴听到这个…
在Linux中有很多有用的故障注入基础设施。 其中之一可能会有助于您的testing工作。
本演示的第7页显示了使用dmsetup伪造块设备问题的dmsetup 。
https://mbroz.fedorapeople.org/talks/DeviceMapperBasics/dm.pdf
md（4）本身有一个名为FAULTY的模式，可以用来模拟读/写错误。
不完善的
FAULTY md模块是为testing目的而提供的。 一个错误的数组只有一个组件设备，并且通常在没有超级块的情况下进行组装，所以创build的md数组可以直接访问组件设备中的所有数据。
可以要求FAULTY模块模拟故障以允许testing其他md级别或文件系统。 可以select故障来触发读取请求或写入请求，并且可以是暂时的（在地址上的后续读取/写入可能成功）或持久性的（随后读取/写入相同的地址将失败）。 此外，读取错误可以是“可修复的”，意味着它们一直持续到在同一地址写入请求。
故障types可以用一个句点来请求。 在这种情况下，在相关types的给定数目的请求之后，故障将重复发生。 例如，如果持续读取错误的周期为100，那么每100次读取请求就会产生一个错误，并且错误的扇区将被logging下来，以致后续读取该扇区也会失败。
记住的错误行业的数量是有限的。 限制耗尽后产生的故障被视为暂时性的。
可以刷新故障扇区列表，清除故障模式的活动列表。
控制它的选项列在mdadm（8）的 -p, --layout= 。
设置故障模式为故障级别时，选项包括：write-transient，wt，read-transient，rt，write-persistent，wp，read-persistent，rp，write-all，read-fixable，rf，clear，flush ， 没有。
每个故障模式后面可以跟一个数字，用作故障发生之间的时间段。 如果没有号码，则在第一个相关请求时会产生一次故障。 有了这个数字，就会在这个请求发生之后产生错误，每过一段时间就会继续产生错误。
通过使用–grow选项设置后续失效模式，可以同时使用多个失效模式。
“清除”或“无”将删除任何未决或定期故障模式，“清除”将清除任何持续性故障。
有一些错误注入下的linux-raid邮件列表存档的例子可以帮助你开始使用md故障注入选项。 =）
对于你的第一个问题：
tar c /my/raid/device/mount/point > /dev/null
将取决于你的发行版的tar在缺less“f”参数的情况下的行为。 我在一个Debian（wheezy）系统上试了这个，它的行为和你所期望的一样 – 归档被写入stdout。 但是在FreeBSD系统上。 它返回一个错误：
tar: Failed to open '/dev/sa0'
更通用的方法是明确指定stdout作为存档：
tar cf - /my/raid/device/mount/point > /dev/null
编辑：Doh！ 或者只是忘记redirect：
tar cf /dev/null /my/raid/device/mount/point
除了Kassandry的出色答案之外，如果您的物理驱动器支持预测性故障，我还会推荐使用SMART。