突然大量文件系统损坏的原因？（“根索引节点不是目录”）

我有一台笔记本电脑运行Maverick（很高兴直到昨天），并带有Patriot Torx SSD。整个分区的LUKS加密；最重要的是一个LVM物理卷；然后在此基础上将根目录和根目录放在ext4逻辑卷中。

昨天我尝试引导它时，它抱怨无法安装根文件系统。运行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在整个文件系统上运行，我可以看到那里的文件名和用户数据看起来像什么。我确实有足够好的备份（轻巧的木头），以至于不值得四处寻找来拉回单个文件，尽管我可能会在重建之前保存未加密磁盘的映像，以防万一。

smartctl不会显示任何错误，内核也不会记录日志。badblocks跨交换lv 运行写模式也不会发现问题。因此，磁盘可能出现故障，但不是很明显。

就像他们所说的那样，我现在基本上是fsck？回到重新安装，也许在磁盘上运行了坏块，然后从备份中恢复？似乎甚至没有足够的数据来提交有意义的错误...

我不记得这台机器上次使用时崩溃了。

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

您认为是什么原因造成的？您还有其他尝试吗？

您的第一个超级块似乎已损坏。超级块有很多副本，因为它是文件系统中最关键的部分。您可以尝试e2fsck使用该-b选项来检查超级块的其他副本是否具有正确的信息。检查e2fsck（8），以获取有关该-b选项以及如何确定其他超级块的位置的更多信息。

IIRC，根目录只有一个副本，因此，如果它已损坏，则必须重新创建它为空。根目录下的原始目录将显示在/ lost + found中，您必须从那里重新定位它们。

Inode表分布在整个分区中。您不太可能会丢失所有这些。可恢复的文件如果无法将文件重定位到其原始目录，则它们也将以/ lost + found结尾。

我以前看过 这与Ubuntu 10.10有关。由于它已发布了几次，因此我将在bug跟踪器上四处看看。可以肯定的是，拍摄磁盘快照，将其擦除，然后将其放入辅助系统中，以查看错误是否会自行重复（以排除磁盘-不太可能的罪魁祸首）。

更新：最终，我确信问题出在某种复杂的SSD故障上，或者我认为内核和SSD之间可能存在交互。我用磁盘替换了它，再也没有遇到麻烦。