linux-ext4 - Re: improved performance in case of data journaling

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:   Thu, 03 Dec 2020 09:20:41 +0100
From:   Martin Steigerwald <martin@...htvoll.de>
To:     Ext4 <linux-ext4@...r.kernel.org>
Cc:     lokesh jaliminche <lokesh.jaliminche@...il.com>,
        Andrew Morton <akpm@...uxfoundation.org>
Subject: Re: improved performance in case of data journaling

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