Re: e2fsck: aborted

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

_______________________________________________
Ext3-users mailing list
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users


[Index of Archives]         [Linux RAID]     [Kernel Development]     [Red Hat Install]     [Video 4 Linux]     [Postgresql]     [Fedora]     [Gimp]     [Yosemite News]

  Powered by Linux