我照看一个只有 512 MB RAM 的旧 Debian linux 机器（运行 etch），但连接了很多外部存储。一个 ext3 文件系统大小为 2.7 TB，fsck 无法检查它，因为它的内存不足，出现如下错误：
分配目录块数组时出错：内存分配失败 e2fsck：中止
我添加了一个 4 GB 的交换分区，但它仍然没有完成，但这是一个 32 位内核，所以我不希望再添加任何内容会有所帮助。
除了引导到 64 位内核之外，还有其他方法可以让 fsck 完成它的检查吗？
AskOverflow.Dev
64 位内核和大量 RAM 将允许 fsck 快速完成。或者，现在 e2fsck 中有一个选项，它会告诉它将所有中间结果存储在一个目录而不是 RAM 中，这非常有帮助。
/etc/e2fsck.conf使用以下内容创建：（并且，显然，确保该目录存在，并且位于具有几 GB 可用空间的分区上）。e2fsck 将运行 SLLOOOOWWWWWWW，但至少它会完成。
当然，这不适用于根 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 特别慢。最后，我暂时放弃了文件系统检查；文件系统应该检查，但没有错误（据我所知），所以我会安排在更方便的时间检查它，因为我们可以承受长达一周的中断。
如果您有一个非常大的文件系统，最好尝试迁移到 64 位内核。在某些情况下，即使使用临时文件，32 位
e2fsck也会耗尽内存（有关如何使用它们，请参阅@womble 的答案或man e2fsck）。我有一个 11 TiB 文件系统用作备份目标的设置 - 带有大量硬链接 - 我最近将它升级到 64 位，只是为了能够在
e2fsck不从外部媒体启动的情况下运行。有问题的机器是一个非常旧的机器，只有 2 GiB 的 RAM，但它确实有一个 64 位 CPU。操作系统是 32 位的，因为它已经升级了十多年，但是在将备份 FS 扩大到超过（我认为）5 TiB 之后，我不再能够在其上运行 e2fsck，尽管有 5 GiB 交换和配置e2fsck为使用暂存文件。不过64位升级后现在好像可以完成了；在运行了大约 18 小时后，至少目前已完成近 80%；以前它永远无法前往该州附近的任何地方。对于为什么它在 32 位系统上总是会失败，我最好的猜测是暂存文件本身的大小。目前其中一个的大小超过 3.3 GiB。
当然，如果 CPU 不支持 64 位，情况就很困难，但几乎所有支持足够大物理磁盘的系统都会遇到这个问题。
e2fsck编辑：上述进程的内存使用示例：如图所示，该进程具有高达 10 GiB 的地址空间，尽管实际
VmData大小仍然在启用 PAE 的系统的 4 GiB 限制内，因此它没有机会在 32 位机器中成功完成。当然，技术上可能 32 位版本以不同方式处理地址空间，但我不会指望它。