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

我照顾一个只有512 MB RAM的旧Debian linux盒（运行etch），但是连接了许多外部存储。一个ext3文件系统的大小为2.7 TB，fsck无法对其进行检查，因为它用尽了内存，并显示如下错误：

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

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

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

64位内核和大量RAM将使fsck顺利完成。另外，e2fsck中现在有一个选项，可以告诉它将所有中间结果存储在目录中而不是RAM中，这将极大地帮助您。/etc/e2fsck.conf使用以下内容创建：

[scratch_files]
directory = /var/cache/e2fsck

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

当然，这不适用于根FS，但是如果进行了交换，则无论如何都要挂载根FS。

我最终尝试了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特别慢。最后，我暂时放弃了文件系统检查。该文件系统应进行检查，但没有错误（据我所知），因此，我将安排在更方便的时间检查它，以便我们可以承受一周的停机时间。