adilger at dilger.ca
Fri May 28 23:22:53 UTC 2010
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 22.214.171.124-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?
More information about the Ext3-users