I've got an FS at $WORK that's giving a whole lot of fsck errors. It starts like so: fsck 1.41.3 (12-Oct-2008) e2fsck 1.41.3 (12-Oct-2008) archive contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Running additional passes to resolve blocks claimed by more than one inode... Pass 1B: Rescanning for multiply-claimed blocks Multiply-claimed block(s) in inode 163841: 101019648 Multiply-claimed block(s) in inode 163842: 101019649 101019650 101019651 101019652 101019653 101019654 101019655 Multiply-claimed block(s) in inode 163843: 101019656 101019657 101019658 101019659 101019660 101019661 101019662 101019663 101019664 101019665 101019666 101019667 101019668 101019669 101019670 101019671 101019672 101019673 101019674 101019675 101019676 101019677 101019678 101019679 101019680 101019681 101019682 101019683 101019684 101019685 101019686 101019687 101019688 101019689 101019690 101019691 101019692 101019693 101019694 101019695 101019696 101019697 101019698 101019699 101019700 101019701 101019702 101019703 101019704 101019705 101019706 101019707 101019708 101019709 101019710 101019711 101019712 101019713 101019714 101019715 101019716 101019717 101019718 101019719 101019720 101019721 101019722 101019723 101019724 101019725 101019726 101019727 101019728 101019729 101019730 101019731 101019732 101019733 101019734 101019735 101019736 101019737 101019738 101019739 101019740 101019741 101019742 101019743 101019744 101019745 101019746 [snip] After a while of this, I get the following error: e2fsck: Can't allocate block element e2fsck: aborted 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? - Morty
A bit late, but.... On Fri, 2 Apr 2010 at 18:08, Morty wrote:> e2fsck: Can't allocate block element > e2fsck: aborted > > Google says the error relates to process memory size required for > large FSs. The FS here is a 1TB FS, created before I started usingHow many inodes are on this filesystem? See http://lkml.org/lkml/2003/2/7/95 for some estimates. Maybe adding more RAM/switching to 64bit (if not already done) might help. Christian. -- BOFH excuse #205: Quantum dynamics are affecting the transistors
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.