我将在过去的一些大型文件系统（大约50TB）上testing'xfs_repair'，因为内存使用率很高。 虽然我只能在正确的文件系统上testing程序，但如果在损坏的系统上testing它们，这将是一件好事。
那么什么是腐败文件系统的最好方法。 如果该方法每次都会重复出现相同的错误，则需要额外的信用….
让人们知道我的意思是在2006年
“要成功检查或运行在多TB文件系统上的修复，您需要：
xfs_repair通常使用的内存比这less，但是这些数字给了你一个大的文件系统，大于80％的完整文件系统需要修复。
FWIW，最后一次出现在内部，有问题的29TB文件系统花费了大约75GB的RAM + swap来修复。
xfs_db有一个选项blocktrash
垃圾桶随机select的文件系统元数据块。 在所选块中随机select的比特发生破坏。 该命令仅在xfs_db的debugging版本中可用。 这对testing
xfs_repair(8)和xfs_check(8)很有用。
例如
xfs_db -x -c blockget -c "blocktrash -s 512109 -n 1000" /dev/xfstest/testfs
dd阻止文件系统所在的设备。 你可以编写脚本，以便重复。 只要在随机地点随机块，然后继续前进。
您可以尝试覆盖块设备的前512个字节（MBR和分区表）。
首先备份：
dd if=/dev/device bs=512 count=1 of=backup.bin
之后再调零
dd if=/dev/zero bs=512 count=1 of=/dev/device
之后，您的机器不应该启动，您可以使用live CDtestingXFS修复。