最近我在RAID阵列中丢失了一个驱动器(从系统收到了一封电子邮件,警告我这件事,这真是太棒了),在一些驱动器重新调整和交换后,我都很安全。但在此过程中,我发现了这条线,这让我开始思考如何在没有实际发生的情况下测试磁盘错误和其他不好的事情。当我运行建议的tar命令时:
tar c /my/raid/device/mount/point > /dev/null它在几秒钟内就完成了,这显然不足以让系统真正读取所有文件(很好地通过一个TiB) -所以我想我的第一个问题是为什么这可能不起作用。如果我这样做:
find . -type f | xargs md5sum这个命令运行得很好,需要很长时间才能完成.但是它也会加载CPU,完成所有的求和工作。这可能比" tar“更快,也可能不容易--我更好奇为什么tar命令没有像我预期的那样工作。
无论如何--第二个问题,也是更普遍的问题:是否有一种方法可以这样做来进行故障注入测试:
这似乎是可行的,但我对linux工具还没有足够的详细知识,这样我就可以在设备级别将块标记为坏块,而不是真正的坏块.
对此有什么想法吗?或者,如果有更好的方法来解决这个问题,我也很高兴听到.
发布于 2015-09-06 09:16:44
Linux中有很多有用的故障注入基础设施。其中之一可能有助于您的测试工作。
本演示文稿第7页展示了一个用dmsetup伪造块设备问题的示例。
https://mbroz.fedorapeople.org/talks/DeviceMapperBasics/dm.pdf
md(4)本身有一个名为FAULTY的模式,可以用来模拟读/写错误。
故障md模块是为测试目的而提供的。一个错误的数组正好有一个组件设备,通常是在没有超级块的情况下组装的,所以创建的md数组提供了对组件设备中所有数据的直接访问。可能会要求错误模块模拟故障,以允许测试其他md级别或文件系统。可以选择错误来触发读请求或写入请求,并且可能是短暂的(地址的后续读/写可能会成功)或持久的(相同地址的后续读/写将失败)。此外,读取错误可能是“可修复的”,这意味着它们将持续到相同地址的写入请求为止。可以通过句点请求故障类型。在这种情况下,在给定数量的相关类型请求之后,故障会反复出现。例如,如果持久读取错误的周期为100,那么每100次读取请求都将生成故障,并且错误扇区将被记录,以便对该扇区的后续读取也将失败。人们记住的错误部门的数量是有限的。该极限耗尽后产生的故障被视为瞬态故障。可以刷新故障扇区的列表,并且可以清除故障模式的活动列表。
控制它的选项在mdadm(8)中-p, --layout=下列出。
当为级别故障设置故障模式时,选项是:写瞬态,wt,读瞬变,rt,写持久化,wp,读持久,rp,写所有,可读可修复,rf,清除,刷新,无.每种故障模式都可以跟随一个数字,该数字用作故障生成之间的一个周期。在没有编号的情况下,故障将在第一个相关请求时生成一次。使用一个数字,故障将在那么多请求之后生成,并将在每次周期过去时继续生成。通过使用-增长选项设置后续的故障模式,多个故障模式可以同时发生.“清除”或“无”将删除任何未决或定期的故障模式,而“刷新”将清除任何持续的故障。
linux-raid邮件列表中的误差注入文档中也有一些示例可以帮助您开始使用md错误注入选项。=)
发布于 2015-09-06 14:34:44
关于你的第一个问题:
tar c /my/raid/device/mount/point > /dev/null将取决于在没有"f“参数的情况下发行版的tar行为。我在Debian ( the )系统上尝试了这一点,它的行为与您所期望的一样--存档是写到stdout的。然而,在FreeBSD系统上。它返回一个错误:
tar: Failed to open '/dev/sa0'一种更普遍的方法是将stdout明确指定为归档文件:
tar cf - /my/raid/device/mount/point > /dev/null编辑: Doh!或者忘了重定向:
tar cf /dev/null /my/raid/device/mount/point 除了Kassandry的出色答案外,如果您的物理驱动器支持预测失败,我也会推荐使用智能。
发布于 2018-06-13 23:28:48
Tar有一个“优化”,如果输出为/dev/null,它几乎什么也不做。
您可以尝试这个来欺骗它来完成工作:
tar c /my/raid/device/mount/point | cat > /dev/null
https://serverfault.com/questions/720380
复制相似问题