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  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:   Fri, 24 Jan 2020 20:57:20 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Colin Zou <colin.zou@...il.com>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: Help: ext4 jbd2 IO requests slow down fsync

On Thu, Jan 23, 2020 at 10:28:47PM -0800, Colin Zou wrote:
> 
> I used to run my application on ext3 on SSD and recently switched to
> ext4. However, my application sees performance regression. The root
> cause is, iosnoop shows that the workload includes a lot of fsync and
> every fsync does data IO and also jbd2 IO. While on ext3, it seldom
> does journal IO. Is there a way to tune ext4 to increase fsync
> performance? Say, by reducing jbd2 IO requests?

If you're not seeing journal I/O from ext3 after an fsync, you're not
looking at things correctly.  At the very *least* there will be
journal I/O for the commit block, unless all of the work was done
earlier in a previous journal commit.

In general, ext4 and ext3 will be doing roughly the same amount of I/O
to the journal.  In some cases, depending on the workload, ext4
*might* need to do more data I/O for the file being synced.  That's
because with ext3, if there is an intervening periodic 5 second
journal commit, some or all of the data I/O may have been forced out
to disk earlier due to said 5 second sync.

What sort of workload does your application do?  How much data blocks
are you writing before each fsync(), and how often are the fsync()
operations?

						- Ted

Powered by blists - more mailing lists