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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
