在大型文件系统上运行 fsck 时内存不足

Question

我照顾着一个只有 512 MB 内存的旧 Debian linux 机器（运行 etch），但连接了很多外部存储。一个 ext3 文件系统的大小为 2.7 TB，fsck 无法检查它，因为它内存不足，出现这样的错误：

   分配目录块数组时出错：内存分配失败
   e2fsck：中止

我已经添加了一个 4 GB 的交换分区，但它仍然没有完成，但这是一个 32 位内核，所以我不认为添加更多会有所帮助。

除了启动到 64 位内核之外，还有其他方法可以让 fsck 完成它的检查吗？

Answer 1

64 位内核和大量 RAM 将允许 fsck 快速完成。或者，现在 e2fsck 中有一个选项可以告诉它把所有的中间结果存储在一个目录而不是 RAM 中，这非常有帮助。/etc/e2fsck.conf使用以下内容创建：

[scratch_files]
directory = /var/cache/e2fsck

（而且，很明显，请确保该目录存在，并且位于具有几 GB 可用空间的分区上）。e2fsck 将运行 SLLOOOOWWWWWWW，但至少它会完成。

当然，这不适用于根 FS，但是如果您有交换，那么无论如何您都无需挂载根 FS。

Answer 2

我最终尝试了 womble 的建议；如果您像我一样以前没有在 e2fsck 中看到过这个新功能，这里有一些可能有用的更多细节。

e2fsck 的“scratch_files”配置选项在 1.40.x 版本期间的某个时候可用。（在我们的例子中，我们必须升级到最新的 Debian 发行版才能获得此功能。）

除了建议的“directory = /var/cache/e2fsk”选项外，还有一些进一步的配置选项可以微调临时文件存储的使用方式。我使用了“dirinfo = false”，因为文件系统有大量文件，但没有这么多目录。如果情况反过来，“icount”选项将是合适的。这些选项都记录在 e2fsck.conf 的手册页中。

顺便说一句，Ted T'so 在这个线程中写了这些选项。

我发现 e2fsck 运行得非常慢，比 Ted 预测的要慢得多。它大部分时间都以 99.9% 的 CPU 利用率运行（在一个非常慢的旧处理器上），这表明将这些数据结构存储在磁盘而不是内存上并不是导致速度变慢的主要原因。可能是文件系统中存储的其他内容使 e2fsck 特别慢。最后，我暂时放弃了文件系统检查；文件系统应该进行检查，但没有错误（据我所知），所以我将安排在更方便的时间检查它，以便我们能够承受为期一周的停机时间。