jbn at forestfield.org
Fri May 28 05:22:58 UTC 2010
> 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
188.8.131.52-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:
Group : System Environment/Base Source RPM:
Size : 1943069 License: GPLv2
Signature : RSA/8, Mon 15 Mar 2010 11:17:10 AM CDT, Key ID
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
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...
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.
More information about the Ext3-users