From: Martin Steigerwald <martin@lichtvoll.de>
To: Ext4 <linux-ext4@vger.kernel.org>
Cc: lokesh jaliminche <lokesh.jaliminche@gmail.com>,
Andrew Morton <akpm@linuxfoundation.org>
Subject: Re: improved performance in case of data journaling
Date: Thu, 03 Dec 2020 09:20:41 +0100 [thread overview]
Message-ID: <1870131.usQuhbGJ8B@merkaba> (raw)
In-Reply-To: <CAKJOkCoUGPctXEcJWZFo+d62CSBmYjxFr1D0j74OY2ijynMyUA@mail.gmail.com>
lokesh jaliminche - 03.12.20, 08:28:49 CET:
> I have been doing experiments to analyze the impact of data journaling
> on IO latencies. Theoretically, data journaling should show long
> latencies as compared to metadata journaling. However, I observed
> that when I enable data journaling I see improved performance. Is
> there any specific optimization for data journaling in the write
> path?
This has been discussed before as Andrew Morton found that data
journalling would be surprisingly fast with interactive write workloads.
I would need to look it up in my performance training slides or use
internet search to find the reference to that discussion again.
AFAIR even Andrew had no explanation for that. So I thought why would I
have one? However an idea came to my mind: The journal is a sequential
area on the disk. This could help with harddisks I thought at least if
if it I/O mostly to the same not too big location/file – as you did not
post it, I don't know exactly what your fio job file is doing. However the
latencies you posted as well as the device name certainly point to fast
flash storage :).
Another idea that just came to my mind is: AFAIK ext4 uses quite some
delayed logging and relogging. That means if a block in the journal is
changed another time within a certain time frame Ext4 changes it in
memory before the journal block is written out to disk. Thus if the same
block if overwritten again and again in short time, at least some of the
updates would only happen in RAM. That might help latencies even with
NVMe flash as RAM usually still is faster.
Of course I bet that Ext4 maintainers have a more accurate or detailed
explanation than I do. But that was at least my idea about this.
Best,
--
Martin
next prev parent reply other threads:[~2020-12-03 8:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-03 7:28 improved performance in case of data journaling lokesh jaliminche
2020-12-03 8:20 ` Martin Steigerwald [this message]
2020-12-03 9:07 ` lokesh jaliminche
2020-12-22 17:47 ` Jan Kara
2020-12-22 22:24 ` Andreas Dilger
2020-12-28 4:06 ` lokesh jaliminche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1870131.usQuhbGJ8B@merkaba \
--to=martin@lichtvoll.de \
--cc=akpm@linuxfoundation.org \
--cc=linux-ext4@vger.kernel.org \
--cc=lokesh.jaliminche@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).