突然大规模文件系统损坏的原因？（“根 inode 不是目录”）

Question

我有一台运行 Maverick 的笔记本电脑（很高兴直到昨天），还有一个 Patriot Torx SSD；整个分区的LUKS加密；一个 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跨文件系统运行，我可以看到那里有文件名和用户数据。我确实有足够好的备份（触摸木头），不值得费力地拉回单个文件，尽管我可能会在重建之前保存未加密磁盘的映像，以防万一。

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

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

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

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

你认为是什么导致了这种情况？你还有什么想尝试的吗？

Answer 1

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

IIRC，根目录只有一个副本，所以如果它被损坏了，它将不得不重新创建，清空。最初在根目录下的目录将出现在 /lost+found 中，您必须从那里重新定位它们。

inode 表分布在分区中。你不太可能失去所有这些。那些可恢复的，如果它们的文件不能重定位到它们的原始目录，它们也会以 /lost+found 结尾。

Answer 2

更新：最终，我确信问题是某种复杂的 SSD 故障，或者我认为可能是内核和 SSD 之间的交互。我把它换成磁盘，就没有再出现问题了。