[Bug 78651] Write performance of ext4 degrades linearly as volume fills

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=78651

--- Comment #8 from Theodore Tso <tytso@mit.edu> ---
*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.