Comment 10 for bug 455024

I ran into the same problem on my ARM 5 machine with 512 MB RAM (Debian squeeze).
It has a LVM system consisting of 4*3 TiB disks.

I needed to shrink an EXT4 file system from 8.5 TiB to something like 7 TiB, and kept getting the "Memory allocation failed" error. So, I tried to reduce it in smaller and smaller increments, but to no avail.

The basic system with the LVM off-line has a swap partition just under 1 GiB (1023.4 MiB according to gdisk).
While resize2fs was running, I was monitoring the mem/swap usage in a separate terminal (using free).
It never got close to filling the swap, but I thought "what the h*ll" and attached another disk with a huge SWAP partition, did swapon, and tried again. Now it worked. Again I monitored with free: It never used more than 1217 MiB of the SWAP.
Perhaps a test of requirements should be implemented (or at least a switch for it)? That way I wouldn't have to run e2fsck after each failed attempt.

Regarding the comment about most common configurations: perhaps you should rethink. I understand that you would not want to introduce something that would have bad consequences for enterprise configurations, but things are changing.
I could have moved all disks to my desktop machine with 16 GiB RAM and done it there, but it would have meant taking hardware apart. The reason the disks are attached to the little ARM box is that I want that storage on-line 24/7 and still be able to sleep at night (no fans).
I think this kind of set-up is becoming more common.

Just my 2 cents...