linux内存分配缺陷,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上与早期版本有相同的问题)