![文件系统突然大规模损坏的原因是什么?(“根 inode 不是目录”)](https://linux22.com/image/530858/%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E7%AA%81%E7%84%B6%E5%A4%A7%E8%A7%84%E6%A8%A1%E6%8D%9F%E5%9D%8F%E7%9A%84%E5%8E%9F%E5%9B%A0%E6%98%AF%E4%BB%80%E4%B9%88%EF%BC%9F%EF%BC%88%E2%80%9C%E6%A0%B9%20inode%20%E4%B8%8D%E6%98%AF%E7%9B%AE%E5%BD%95%E2%80%9D%EF%BC%89.png)
我有一台运行 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
在交换逻辑卷上运行写入模式也没有发现问题。因此磁盘可能出现故障,但不是很明显。
此时,我基本上就像他们说的一样,被 fscked 了?重新安装,也许在磁盘上运行坏块,然后从备份中恢复?似乎甚至没有足够的数据来记录一个有意义的错误……
我不记得上次使用这台机器时它崩溃了。
此时,我怀疑是错误或内存损坏导致它在上次运行时在磁盘上写入垃圾,或者是 SSD 的某种细微故障模式。
您认为是什么原因导致的?您还会尝试其他方法吗?
答案1
看来您的第一个超级块已损坏。超级块有很多副本,因为它是文件系统中最关键的部分。您可以尝试e2fsck
使用该-b
选项检查超级块的其他副本是否具有正确的信息。检查e2fsck(8)有关该-b
选项的更多信息,以及如何确定附加超级块的位置。
我记得,根目录只有一个副本,所以如果它被损坏了,就必须重新创建,清空。 原来位于根目录下的目录将出现在 /lost+found 中,您必须从那里重新定位它们。
Inode 表遍布整个分区。您不太可能丢失所有表。可恢复的表,如果其文件无法重新定位到其原始目录,它们也将以 /lost+found 结尾。
答案2
我以前见过这种情况。这与 Ubuntu 10.10 有关。我会查看错误跟踪器,因为它已经发布过几次了。为确保万无一失,请对磁盘进行快照,擦除它,然后将其放入辅助系统中,看看错误是否会重复出现(以排除磁盘 - 不太可能是罪魁祸首)。
答案3
更新:最终,我确信问题出在某种复杂的 SSD 故障上,或者我猜可能是内核和 SSD 之间的相互作用。我用磁盘替换了它,之后就再也没有遇到问题了。