linux – 10TB ext3 RAID 6的fsck的主要问题(内存分配失败等)

我最近在 linux md软件RAID 6设置中添加了第7个2TB驱动器.在md完成从6到7个驱动器(从8到10TB)重新整形阵列后,我仍然可以毫无问题地安装文件系统.为了准备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上结算了,我无法超越它.

我花了最后几天试图寻找修复程序并找到以下3个“解决方案”：

>使用64位Linux. / proc / cpuinfo包含lm作为处理器标志之一,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- *文件.所以这似乎也有其预期的效果.
>为机器添加更多内存或交换空间. 12GB的RAM和32GB的交换分区就足够了,不是吗？

不用说：没有任何帮助,否则我不会写在这里.

当然,现在驱动器标记为坏,我无法再安装它.那么,截至目前,由于磁盘检查,我丢失了8TB的数据？！？！？

这给我留下了3个问题：

>我有什么办法可以修复这个驱动器(记住,在我运行fsck之前一切都很好！),而不是花一个月时间学习ext3磁盘格式,然后尝试用十六进制编辑器手动修复它？
>怎么可能,像ext3这样流行的文件系统的fsck作为任务关键的东西仍然有这样的问题？特别是因为ext3已经有十多年了.
>有没有ext3的替代品,没有这些基本的可靠性问题？也许是jfs？

(我现在在64位Debian Wheezy 7.1上使用e2fsck 1.42.5,但在32位Debian Squeeze上与早期版本有相同的问题)

解决方法

只需重建阵列并从备份中恢复数据. RAID的重点是尽量减少停机时间.通过乱搞并尝试解决这样的问题,您只是增加了停机时间,从而无法实现RAID的全部目的. RAID不能防止数据丢失,它可以防止停机.