adilger at dilger.ca
Sat May 29 02:47:24 UTC 2010
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
> 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.
More information about the Ext3-users