[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Assertion failure in do_get_write_access() at fs/jbd/transaction.c:746

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]