突然大规模文件系统损坏的原因? (“根目录不是目录”)

我有一台运行Maverick的笔记本电脑(非常愉快,直到昨天),用爱国者Torx SSD; 整个分区的LUKSencryption; 一个lvm的物理量在上面; 然后在其上的ext4逻辑卷的home和root。

当我试图启动它昨天,它抱怨说,它无法挂载根文件系统。 运行fsck,基本上每个inode似乎都是错的。 家庭和根文件系统都显示类似的问题。 检查备份超级块没有帮助。

e2fsck 1.41.12 (17-May-2010) lithe_root was not cleanly unmounted, check forced. Resize inode not valid. Recreate? no Pass 1: Checking inodes, blocks, and sizes Root inode is not a directory. Clear? no Root inode has dtime set (probably due to old mke2fs). Fix? no Inode 2 is in use, but has dtime set. Fix? no Inode 2 has a extra size (4730) which is invalid Fix? no Inode 2 has compression flag set on filesystem without compression support. Clear? no Inode 2 has INDEX_FL flag set but is not a directory. Clear HTree index? no HTREE directory inode 2 has an invalid root node. Clear HTree index? no Inode 2, i_size is 9581392125871137995, should be 0. Fix? no Inode 2, i_blocks is 40456527802719, should be 0. Fix? no Reserved inode 3 (<The ACL index inode>) has invalid mode. Clear? no Inode 3 has compression flag set on filesystem without compression support. Clear? no Inode 3 has INDEX_FL flag set but is not a directory. Clear HTree index? no .... 

在文件系统中运行strings ,我可以看到里面有文件名和用户数据。 我确实有足够好的备份(触摸木头),不需要扯开个别文件,尽pipe我可能会在重build之前保存未encryption磁盘的映像,以防万一。

smartctl不会显示任何错误,内核日志也不会显示。 在交换LV中运行写入模式的badblocks也没有发现问题。 所以磁盘可能会失败,但不是一个明显的方式。

在这一点上,我基本上,正如他们所说,fscked? 回到重新安装,可能在磁盘上运行badblocks,然后从备份恢复? 甚至似乎没有足够的数据来提交有意义的错误…

我不记得这台机器上次使用时发生了故障。

在这一点上,我怀疑一个错误或内存损坏导致它在最后一次运行时在磁盘上写入垃圾,或者某种微妙的故障模式。

你觉得这会造成什么? 还有什么你想尝试吗?

看来你的第一个超级块是腐败的。 有超级块的许多副本,因为它是文件系统中最关键的部分。 您可以使用-b选项尝试e2fsck ,以检查超级块的不同副本是否具有正确的信息。 请查看e2fsck(8)了解更多关于-b选项的信息,以及如何确定其他超级块的位置。

IIRC,只有根目录的一个副本,所以如果它被损坏,它将不得不被重新创build,空的。 最初在根目录下的目录将显示在/ lost + found中,您将不得不从这里重新定位它们。

Inode表遍布整个分区。 这是不可能的,你会失去所有的人。 那些可恢复的,如果他们的文件不能被重新定位到他们原来的目录,他们也将结束/ lost + found。

我以前见过这个。 这与Ubuntu 10.10有关。 我会环视bug跟踪器,因为它已经发布了几次。 可以肯定的是,对磁盘进行快照,将其擦除,然后将其放在辅助系统中,以查看该错误是否重复(排除磁盘 – 不可能是罪魁祸首)。

更新:最终,我确信这个问题是某种复杂的SSD故障,或者我认为可能是内核和SSD之间的交互。 我用磁盘取代了它,我再也没有麻烦了。