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