https://bugzilla.kernel.org/show_bug.cgi?id=78651 --- Comment #8 from Theodore Tso <tytso@xxxxxxx> --- *Very* interesting. If increasing the journal helped significantly, I'd really like to get the traces from enabling jbd2_checkpoint and jbd2_run_stats, with both with the original and new journal size. (Note, you'll need to use "trace-cmd report" to get the actual traces, and then delete the trace.dat file between runs. The traces will be quite voluminous, but they should compress well.) To explain what you'll see: jbd2/sda3-8-331 [000] ...2 35527.318772: jbd2_run_stats: dev 8,3 tid 14512411 wait 0 request_delay 0 running 5290 locked 0 flushing 0 logging 0 handle_count 33 blocks 7 blocks_logged 8 This means that we spent a bit over five seconds letting the transaction run, and in that transaction contained 33 handles ("micro transactions") which covered 7 blocks, and it used 8 blocks of space in the journal. jbd2/sda3-8-331 [000] ...2 35534.133232: jbd2_run_stats: dev 8,3 tid 14512413 wait 0 request_delay 0 running 440 locked 0 flushing 0 logging 10 handle_count 27 blocks 8 blocks_logged 9 This is an example of a transaction that only ran for less than half a second (440 jiffies); since it ran for less than the default five seconds, we can surmise that there was an explicit fsync() that triggered the transaction. If the number of blocks logged was very high, it's possible it was triggered by running out of room in the journal, but in that case, you'd see a lot of jbd2_checkpoint tracepoint data as well. So now that we know that the journal size is making a difference, this will allow us to figure out *why* the journal size is making a difference. -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
