e2fsck: aborted

[J.B. Nicholson-Owens]

Morty wrote:
> Google says the error relates to process memory size required for
> large FSs.  The FS here is a 1TB FS, created before I started using
> largefile and largefile4 for large FSs.  When I mount it, some data
> seems to be lost.  Anything I can do other than recover from backup?

I too just experienced this with a 1TB EXT3 filesystem I can't mount. 
I'm using Fedora GNU/Linux 13 on a 64-bit AMD system with 4GB RAM 
(around 3.6GiB of RAM is visible according to the system monitor program 
one runs via System -> About This Computer).  I'm running Linux kernel 
2.6.33.4-95.fc13.x86_64 (a Fedora kernel package).

I'm using the fsck that came with Fedora 13 (plus all of its updates):

$ rpm -qi e2fsprogs
Name        : e2fsprogs                    Relocations: (not relocatable)
Version     : 1.41.10                           Vendor: Fedora Project
Release     : 6.fc13                        Build Date: Mon 15 Mar 2010 
10:53:30 AM CDT
Install Date: Wed 07 Apr 2010 02:17:41 PM CDT      Build Host: 
xb-01.phx2.fedoraproject.org
Group       : System Environment/Base       Source RPM: 
e2fsprogs-1.41.10-6.fc13.src.rpm
Size        : 1943069                          License: GPLv2
Signature   : RSA/8, Mon 15 Mar 2010 11:17:10 AM CDT, Key ID 
7edc6ad6e8e40fde



I tried to run

$ sudo fsck.ext3 -y -C0 /dev/sdc1

(-C0 because I wanted to see how far this would go and -y because I got 
tired of answering "y"es to all the questions)

fsck aborted itself.  I tried looking up this error response and reading 
e2fsck.config manpage and then I added a config file:

$ cat /etc/e2fsck.conf
[scratch_files]
	numdirs_threshold = 2
	directory = /var/cache/e2fsck
	dirinfo = true
	icount = true

followed by re-running the fsck command above.  There's over 780GiB free 
on / (where the scratch directory is mounted), plenty of room to let 
fsck avoid using RAM.

Both times the fsck process gets to 70% completion and starts a long 
process of relocating data.  That ends with:

[...thousands of lines like the following...]
Relocating group 7451's block bitmap from 244154368 to 244154626...
Relocating group 7451's inode bitmap from 244154369 to 244154627...
Relocating group 7451's inode table from 244154370 to 244154628...
Relocating group 7452's block bitmap from 244187136 to 244187394...
Relocating group 7452's inode bitmap from 244187137 to 244187395...
Relocating group 7452's inode table from 244187138 to 244187396...
e2fsck: aborted

and I'm still left with a volume I can't mount.

I was surprised that even though I specified I wanted the fsck to use 
the scratch directory the files in the scratch directory aren't very 
large and all of my remaining RAM is still used by fsck.  It's as if 
using the scratch directory only made the process run slower but didn't 
change anything to do with (what I'm reading) is the main problem--not 
enough RAM to hold the data fsck needs while it runs.

I can't add more RAM to the system, 4GB is its max.

Has there been any improvement on doing fsck on large volumes (where 
"large" means larger than what fsck can work with in available system 
RAM)?  I'd gladly trade repair time and disk space for an fsck that 
worked.  Any ideas on how I can get fsck to run and actually fix this 
volume would be welcome.

Thanks.