Re: 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