Burton Windle wrote: > > I guess this could be filed under the 'shot myself in the foot' section, > but I figured I'd report it anyways.. > > Kernel 2.5.50-bk6, x86, preempt, PIIX IDE, ext3 fs. > > I dd'ed the first part of a ext3 partition to tmp, then mounted it via > loopback. (the image passed a fsck, except for warning about corrupt part. > table or superblock) Well that is very cruel of you, but a good and robust filesystem should survive such abuse. > I tried to 'cd' into a directory within that mount, > and got this: > > EXT3 FS 2.4-0.9.16, 02 Dec 2001 on loop(7,0), internal journal > EXT3-fs: mounted filesystem with ordered data mode. > Assertion failure in do_get_write_access() at fs/jbd/transaction.c:746: "handle- > >h_buffer_credits > 0" OK, I think I see what happened. In ext3_dirty_inode(), we open a transaction which reserves just a single disk block. Because that is all we expect to write. But when you get all the way down to ext3_do_upodate_inode(), the corrupted inode data leads the filesytem to think that the file has a size larger than 2G. This triggers the logic in ext3_do_update_inode() which updates the superblock to say "this filesystem now has files which are larger than 2G". But that requires a journalled superblock write. We didn't reserve a second block in the transaction for that, and blam. A robust fix for this is to update all callers of ext3_do_update_inode() to reserve an additional block for that eventuality. _______________________________________________ Ext3-users@redhat.com https://listman.redhat.com/mailman/listinfo/ext3-users
