search for: t_updat

This version fixes three bugs in the 2nd patch of this series that caused kernel BUG when the system was under race. We weren't accounting with t_oustanding_credits correctly, and there were race conditions caused by the fact the I had overlooked the fact that __jbd2_log_wait_for_space() and jbd2_get_transaction() requires j_state_lock to be write locked. Theodore Ts'o (3): jbd2: Use

jbd2_journal_restart() would restart a handle. In this function, it calls start_this_handle(). Before calling start_this_handle()?subtract 1 from transaction->t_updates. If start_this_handle() succeeds, transaction->t_updates increases by 1 in it. But if start_this_handle() fails, transaction->t_updates does not increase. So, when commit the handle's transaction in jbd2_journal_stop(), the assertion is false, and then trigger a bug. The assertion is as...

...race: [sleep_on+75/124] [journal_commit_transaction+357/4044] [do_IRQ+221/236] [.text.lock.sched+131/471] [kjournald+326/540] [commit_timeout+0/12] [arch_kernel_thread+40/56] This sleep_on is at line 87 in commit.c (journal_commit_transaction) where it is waiting for t_updates to be 0. At this point, t_state is T_LOCKED, so presumably those nfsd threads above are waiting on kjournald. But what is kjournald really waiting for? My first though was the two nfsd threads in: nfsd Call Trace: [sleep_on+75/124] [log_wait_commit+74/136] [journal_stop+408/432]...

...... The last "if (...)" represents 2 additional conditions which can cause the thread to go to sleep in start_this_handle(), and loop back to the "repeat" label. In looking at how the wake_up() occurs, there exists the following section of code: transaction->t_updates--; if (!transaction->t_updates) { wake_up(&journal->j_wait_updates); if (journal->j_barrier_count) wake_up(&journal->j_wait_transaction_locked); } It would seem to me that this wake_up() will end up being a no-op, as t...

All, I am running into a situation in which one of my ext3 filesystems is getting hung during normal usage. There are three ext3 filesystems on a CompactFLASH. One is mounted as / and one as /tmp. In my test, I am copying a 100 MB file from /root to /tmp repeatedly. While doing this test, I eventually see the copying stop, and any attempts to access /tmp fail - if I even do ls /tmp the

The following 6 patches cleanup the jbd code and kill about 200 lines. First of 4 patches can apply to 2.6.13-git8 and 2.6.13-mm2. The rest of them can apply to 2.6.13-mm2. fs/jbd/checkpoint.c | 179 +++++++++++-------------------------------- fs/jbd/commit.c | 101 ++++++++++-------------- fs/jbd/journal.c | 11 +- fs/jbd/revoke.c | 158

...nal has aborted Feb 4 00:08:24 server1 last message repeated 18 times Feb 4 00:08:24 server1 kernel: EXT3-fs error (device dm-0) in ext3_reserve_inode_write: Journal has aborted Feb 4 00:08:24 server1 kernel: Assertion failure in journal_stop() at fs/jbd/transaction.c:1344: "transaction->t_updates > 0" Feb 4 00:08:24 server1 kernel: ------------[ cut here ]------------ Feb 4 00:08:24 server1 kernel: kernel BUG at fs/jbd/transaction.c:1344! Feb 4 00:08:24 server1 kernel: invalid operand: 0000 [#1] Feb 4 00:08:24 server1 kernel: Modules linked in: nfsd exportfs lockd nfs_acl parp...