It is best to try to move to a 64-bit kernel, if you have a very large filesystem. In some cases a 32-bit
e2fsck will run out of memory even with scratch files (for how to use them, see @womble's answer or
I had such a setup with an 11 TiB filesystem that is used as a backup target – with loads of hard links – and I recently upgraded it to 64-bit solely to be able to run
e2fsck without the recourse of booting from an external media. The machine in question is a very old box, with only 2 GiB of RAM, but it does have a 64-bit CPU. The OS was 32-bit because it had simply been upgraded for well over a decade, but after enlarging the backup FS to over (I think) 5 TiB I was no longer able to run e2fsck on it, despite having a 5 GiB swap and configuring
e2fsck to use scratch files.
However, after the 64-bit upgrade it now seems to be able complete; at least it is currently nearly 80% done, after having run for about 18 hours; previously it was never able to proceed to anywhere near this state. My best guess for why it will always fail on a 32-bit system is the sizes of the scratch files themselves; currently one of them is over 3.3 GiB in size.
Of course, if the CPU has no 64-bit support, the situation is difficult, but nearly all systems that support big enough physical disks to run into this problem will probably have it.
EDIT: an example of the memory usage of the said
VmPeak: 10687568 kB
VmSize: 10687568 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 1706284 kB
VmRSS: 715104 kB
RssAnon: 417312 kB
RssFile: 297792 kB
RssShmem: 0 kB
VmData: 3151052 kB
VmStk: 132 kB
VmExe: 232 kB
VmLib: 1888 kB
VmPTE: 8676 kB
VmSwap: 1550760 kB
As shown, the process has a whopping 10 GiB address space, even though the actual
VmData size remains well within the 4 GiB limit of a PAE-enabled system, so it would have no chance of completing successfully in a 32-bit machine. Of course, it is technically possible that the 32-bit version handles the address space differently, but I wouldn't count on it.