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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 07 Jul 2014 12:29:38 +0000
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 78651] Write performance of ext4 degrades linearly as volume
 fills

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

--- Comment #8 from Theodore Tso <tytso@....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.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html