On Thu 24-10-19 15:09:08, Jan Kara wrote: > On Sat 19-10-19 15:19:33, Theodore Y. Ts'o wrote: > > Hi Jan, > > > > I've tried applying this patch set against 5.4-rc3, and I'm finding a > > easily reproducible failure using: > > > > kvm-xfstests -c ext3conv ext4/039 > > > > It is the BUG_ON in fs/jbd2/commit.c, around line 570: > > > > J_ASSERT(commit_transaction->t_nr_buffers <= > > atomic_read(&commit_transaction->t_outstanding_credits)); > > > > The failure (with the obvious debugging printk added) is: > > > > ext4/039 [15:13:16][ 6.747101] run fstests ext4/039 at 2019-10 > > -19 15:13:16 > > [ 7.018766] Mounted ext4 file system at /vdc supports timestamps until 2038 ( > > 0x7fffffff) > > [ 8.227631] JBD2: t_nr_buffers 226, t_outstanding_credits=223 > > [ 8.229215] ------------[ cut here ]------------ > > [ 8.230249] kernel BUG at fs/jbd2/commit.c:573! > > ... > > > > The full log is attached (although the stack trace isn't terribly > > interesting, since this is being run out of kjournald2). > > Thanks! Somehow this escaped my testing although I thought I have run ext3 > configuration... Anyway we are reserving too few space in this case - with > some debugging added: > > [ 80.296029] t_buffers: 222, t_outstanding_credits: 219, > t_revoke_written: 23, t_revoke_reserved: 12, t_revoke_records_written > 11432, t_revoke_records_reserved 11432, revokes_per_block: 1020 > > Which is really puzzling because it would suggest that revokes_per_block is > actually wrong. Digging more into this. Yeah, ext4 was updating journal features in this case but j_revoke_records_per_block didn't get properly updated. Fixed now. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
