今天，在解压一个非常大的存档后，我们的一台 Red Hat 服务器变得无响应。重启后，我们收到以下文件系统错误。
Inode 93464 太大 意外不一致 手动运行 fsck
运行 fsck 会立即提示我们截断 Inode。
这引发了许多问题。例如，Inode 是如何变得太大的？如果截断所述 Inode，会发生什么。我假设您失去了对 Inode 引用的文件和/或目录的逻辑访问权限以及对其他链接 Inode 的任何其他引用。我们正在运行 Redhat Enterprise 4。
答案1
检查你的 e2fsprogs 版本（例如e2fsck -V）。之前显然有一个 bug版本 1.40.2这可能会导致 e2fsck（由 EXT2/EXT3 文件系统的 fsck 调用）错误地报告这种类型的文件系统损坏：
修复 e2fsck 中的一个错误，该错误导致它在最后一个条目的 rec_len 过大时错误地挽救目录。这导致报告无意义的文件系统损坏，并且需要第二次运行 e2fsck 才能完全修复目录。
我访问的 RHEL 4 服务器使用的是 1.35 版本，所以这可能是导致问题的真正原因。可能需要安装较新版本并再次运行 fsck 以确保无误。
如果这没有帮助，那可能确实是文件系统问题。根据此主题，如果您的目录包含大量文件（数百万或更多），则似乎会发生这种情况。使用 fsck“修复”它将导致 inode 被截断，正如您所看到的。对于目录 inode，截断将导致目录“丢失”文件，并且这些孤立文件最终将位于文件系统的 lost+found 目录中。它们将以其 inode 编号命名，而不是其原始名称，因此尽管您仍然拥有这些文件，但可能很难区分它们。