linux-ext4 - Problem with ext4_sync_file in no-journal mode.

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-next>] [day] [month] [year] [list]

Message-Id: <1251222245.20219.25.camel@bobble.smo.corp.google.com>
Date:	Tue, 25 Aug 2009 10:44:05 -0700
From:	Frank Mayhar <fmayhar@...gle.com>
To:	linux-ext4@...r.kernel.org
Subject: Problem with ext4_sync_file in no-journal mode.

Our powerfail testing turned up an odd regression when using fsync() in
no-journal mode to force data to the device.  We saw loss rates (both
file and data) that were much higher than the same test using ext2 (60+%
loss versus <10%).  We've done some investigation and one thing that
stood out was that in the no-journal case, ext4_sync_file() was just
calling sync_inode() (and nothing else), while ext2_sync_file(), for
comparison, was also calling sync_mapping_buffers() to actually push the
data out.

I therefore hacked ext4_sync_file() to call sync_mapping_buffers() in
the no-journal case; when we reran the test we saw that the loss rate
dropped from 60+% to around 50%.  While it's clear that we have more
work to do in this area, this is a significant improvement.  It appears
that this was just missed when we did the no-journal work.  Do you guys
concur?

The other interesting bit of this is that ext4 no-journal without using
fsync() has, apparently, basically the same loss rate as ext2 with
fsync().
-- 
Frank Mayhar <fmayhar@...gle.com>
Google, Inc.

--
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