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
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
04-16-2010, 03:50 AM
Christian Kujau
e2fsck: aborted
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 using
How 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
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
05-28-2010, 05:22 AM
"J.B. Nicholson-Owens"
e2fsck: aborted
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:
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@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
05-28-2010, 11:22 PM
Andreas Dilger
e2fsck: aborted
On 2010-05-27, at 23:22, J.B. Nicholson-Owens wrote:
> 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 can't imagine that there is a shortage of RAM for a 1TB filesystem. We run e2fsck on 3x 8TB filesystems with only 2GB of 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
What is more important to know is why it thinks the block/inode bitmaps and
inode table need to be relocated in the first place. That is a pretty serious/significant problem that should normally never been seen, since the bitmaps never move, and there are backups of all the group descriptors (that say where the bitmaps are located).
> and I'm still left with a volume I can't mount.
Did you do something like resize your filesystem before having this problem?
Cheers, Andreas
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
05-28-2010, 11:49 PM
"J.B. Nicholson-Owens"
e2fsck: aborted
Andreas Dilger wrote:
What is more important to know is why it thinks the block/inode
bitmaps and inode table need to be relocated in the first place. That
is a pretty serious/significant problem that should normally never
been seen, since the bitmaps never move, and there are backups of all
the group descriptors (that say where the bitmaps are located).
I was unaware this was such a serious issue. Unfortunately I have no
helpful information to offer.
Did you do something like resize your filesystem before having this
problem?
No resizing at all; this drive has always had one volume on it at max
size (1TB minus whatever ext3 needs for its own bookkeeping).
I used to have this drive mounted in another computer running gNewSense
(latest + updates) but I thought I'd detach it and put the drive on this
64-bit 4GB machine.
Does it matter that the other system was a 32-bit system? Would it be
wise to attempt fsck on a 32-bit machine?
Thanks for your input.
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
05-29-2010, 02:47 AM
Andreas Dilger
e2fsck: aborted
On 2010-05-28, at 17:49, J.B. Nicholson-Owens wrote:
> Andreas Dilger wrote:
>> What is more important to know is why it thinks the block/inode
>> bitmaps and inode table need to be relocated in the first place. That
>> is a pretty serious/significant problem that should normally never
>> been seen, since the bitmaps never move, and there are backups of all
>> the group descriptors (that say where the bitmaps are located).
>
> I was unaware this was such a serious issue. Unfortunately I have no
> helpful information to offer.
Unless you have the original output from the first e2fsck run, it will be quite difficult to determine what actually went wrong here.
>> Did you do something like resize your filesystem before having this
>> problem?
>
> No resizing at all; this drive has always had one volume on it at max size (1TB minus whatever ext3 needs for its own bookkeeping).
>
> I used to have this drive mounted in another computer running gNewSense
> (latest + updates) but I thought I'd detach it and put the drive on this
> 64-bit 4GB machine.
>
> Does it matter that the other system was a 32-bit system? Would it be
> wise to attempt fsck on a 32-bit machine?
It shouldn't make any difference, but it isn't impossible that there is some kind of bug involved, since I doubt this gets tested all too often. That said, it seems unlikely, since I'm sure it _does_ happen often enough that it would be reported. It wouldn't hurt to give it a try on the original 32-bit system, but I fear that even if that were the cause the later e2fsck runs may have changed the filesystem enough that it will be hard to recover.
Cheers, Andreas
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
e2fsck: aborted
