我最近添加了第七个2TB驱动器到一个Linux md软件RAID 6设置。 md完成从6到7驱动器（从8到10TB）的arrays整形后，我仍然能够安装文件系统没有问题。 为了准备resize2fs，我然后卸载分区并运行fsck -Cfyv ，并且遇到了数以百万计的随机错误。 这里是一个简短的摘录：
Pass 1: Checking inodes, blocks, and sizes Inode 4193823 is too big. Truncate? yes Block #1 (748971705) causes symlink to be too big. CLEARED. Block #2 (1076864997) causes symlink to be too big. CLEARED. Block #3 (172764063) causes symlink to be too big. CLEARED. ... Inode 4271831 has a extra size (39949) which is invalid Fix? yes Inode 4271831 is in use, but has dtime set. Fix? yes Inode 4271831 has imagic flag set. Clear? yes Inode 4271831 has a extra size (8723) which is invalid Fix? yes Inode 4271831 has EXTENTS_FL flag set on filesystem without extents support. Clear? yes ... Inode 4427371 has compression flag set on filesystem without compression support. Clear? yes Inode 4427371 has a bad extended attribute block 1242363527. Clear? yes Inode 4427371 has INDEX_FL flag set but is not a directory. Clear HTree index? yes Inode 4427371, i_size is 7582975773853056983, should be 0. Fix? yes ... Inode 4556567, i_blocks is 5120, should be 5184. Fix? yes Inode 4566900, i_blocks is 5160, should be 5200. Fix? yes ... Inode 5628285 has illegal block(s). Clear? yes Illegal block #0 (4216391480) in inode 5628285. CLEARED. Illegal block #1 (2738385218) in inode 5628285. CLEARED. Illegal block #2 (2576491528) in inode 5628285. CLEARED. ... Illegal indirect block (2281966716) in inode 5628285. CLEARED. Illegal double indirect block (2578476333) in inode 5628285. CLEARED. Illegal block #477119515 (3531691799) in inode 5628285. CLEARED.
压缩？ 最大化？ 我从来没有在这台机器附近的任何地方的ext4！
现在，问题是fsck不断死亡与以下错误信息：
Error storing directory block information (inode=5628285, block=0, num=316775570): Memory allocation failed
起初我可以简单地重新运行fsck，它会死在一个不同的inode中，但是现在已经解决了5628285，我无法超越它。
我花了最后几天试图寻找修复这个，并find以下3个“解决scheme”：
/proc/cpuinfo包含lm作为处理器flags ， getconf LONG_BIT返回64 ， uname -a有这样的说法： Linux <servername> 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux 。 应该都很好，不是吗？ [scratch_files] / directory = /var/cache/e2fsck到/etc/e2fsck.conf 。 那么每次我重新运行fsck，它会在/var/cache/e2fsck目录中添加另一个500K *-dirinfo-*和一个8M *-icount-*文件。 所以这似乎也有其预期的效果。 不用说，没有什么帮助，否则我不会写在这里。
当然，现在驱动器坏了，我不能再安装了。 所以，就目前而言，由于磁盘检查，我丢失了8TB的数据？！？！？
这给我留下了三个问题：
（我现在在64位Debian Wheezy 7.1上使用e2fsck 1.42.5，但是在32位Debian Squeeze上有一个早期版本的问题）
只需重buildarrays并从备份中恢复数据即可。 RAID的全部重点是尽量减less停机时间。 通过搞乱和试图解决这样的问题，你只是增加你的宕机时间，破坏RAID的整个目的。 RAID不防止数据丢失，防止停机。
在玩fsck之后，我find了一些补救措施：
防止“内存分配失败”错误
fsck似乎有一个内存泄漏的主要问题。 如果它运行在一个文件系统上有一些问题（真实的或想象的），它会一个接一个地“修复”（请参阅原始问题中的屏幕转储）。 因为它这样做，它消耗越来越多的内存（也许保持更改日志？）。 几乎没有界限。 但是， fsck可以随时取消（Ctrl-C）并重新启动。 在这种情况下，它会继续停止的地方，但它的内存使用被重置为一无所有（一段时间）。
考虑到这一点，需要做的三件事是：
fsck如何使用可用的内存有所不同） fsck运行了大约12个小时） 注：我不知道是否取消和重新启动fsck带来了任何其他危险（可能是），但它似乎为我工作。
如果发生“内存分配失败”错误（重要！），处理所造成的损坏
fsck以最糟糕的方式处理Memory allocation failed错误：我破坏了完美的数据。 我不知道为什么，但我的猜测是，它做了一些最终的数据 – 写入磁盘的事情，它保存在内存中，这（由于错误），同时已经损坏。
在我的情况下，最明显的问题是，当我在错误后重新启动fsck时，它有时会报告一个损坏的超级块。 问题是：我不知道如何破坏超级块，特别是在没有报告它被损坏的情况下。 也许，如果在错误后重新启动，它会使用损坏的超级块中发现的不正确的驱动器元数据进行所有进一步的检查，并最终修复那些并不存在的“问题”，从而破坏过程中的良好数据。
因此，如果fsck与Memory allocation failed错误一起死亡，则需要使用-b参数重新启动，以使用备份超级块（希望）不会由于错误而损坏。 备份超级块的位置可以使用mke2fs -n /dev/... 。
由于我不知道如果fsck在选中备份超级块的情况下死机会发生什么情况，我通常会立即中止fsdk ，直到进入Pass 1: Checking inodes, blocks, and sizes ，然后在没有-b情况下再次重新启动，此时它开始时不抱怨一个糟糕的超级块。 也就是说， fsck -b所做的第一件事就是恢复主要的超级块。
现在我们一直在等待的一个：
如何挂载文件系统而不让fsck运行完成
这个，我偶然发现：事实certificate，运行fsck -b并在打印Pass 1: Checking inodes, blocks, and sizes （在发现任何错误之前）中止后，文件系统将保留在（Yay！我已经把所有的数据都拿回来了！）。
（注意：使用mount -o force可能有另外一种方法，但在我的情况下不需要。）
如何避免所有这些问题摆在首位
似乎有两种方法：
-N fsck 。 如果显示任何问题，请删除整个fs并从备份中恢复所有内容。 因为在这种情况下，一个人会非常依赖备份，我build议保留一个备份的备份。 此外，使用复制工具可以确保恢复过程不会在过程中产生随机错误（在处理TB数据时，万亿r / w的MTBF很小）。 请确保计划产生的停机时间，因为多TB恢复可能需要一段时间… fsck ）对于真正的生产使用来说还不够强大（还？）。 fsck处理内存错误的方式以及首先发生错误的事实在我看来是不可接受的。 我从现在开始尝试xfs，但还没有足够的经验来判断它是否更好。