linux-ext4 - Re: Does ext4 send FUA to flush disk cache

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20110411184433.GA3682@thunk.org>
Date:	Mon, 11 Apr 2011 14:44:33 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Mark Busheman <markbusheman@...il.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Does ext4 send FUA to flush disk cache

On Mon, Apr 11, 2011 at 11:23:23AM -0700, Mark Busheman wrote:
> Thanks Ted for replying.
> 
> >> FUA doesn't cause a cache flush.
>
> Thanks for correcting. Yes FUA does not flush cache. When the FUA
> bit is set in the write command, the drive make sure that the data
> goes to platters and not to be put into its cache for latter writes.

For that particular write only; and it forces the write to go directly
to the disk, bypassing any seek-mitigation algorithms the disk might
use.  It's good if you only have a very small number of sectors
(ideally one) which you need to write to the disk.  In the case of
ext4, we want to make sure all of the data and metadata blocks sent to
disk are flushed down to the platters, so FUA isn't as useful to us,
and so we don't use it.

> >> Ext4 does send cache flush commands, or barriers, to make sure the data written to disk
> >> is flushed all the way down to the disk platters on transaction commits.
>  I have few questions on this and need help:
> a. To achieve the above, is any specific options that need to be used
> while mounting?

No, not for ext3.

> b. Are the above mentioned things done only for data=journal or for
> other modes such as
> data=ordered and writeback?

It's done for all journalling modes.

> c. Are they done for metadata, journal and data writes?

Yes; see below.

> d. Can I know what are the commands sent to the drives to do the cache
> flush commands
> or barriers? Would like to find if the drive support the commands?

We use the CACHE FLUSH or CACHE FLUSH EXT command, as appropriate for
IDE/SATA disks.  There is an equivalent command for SCSI, but in
essence it establishes a barrier; all writes sent to the disk before
the CACHE FLUSH/CACHE FLUSH EXT must be written to the disk before the
barrier returns.

When we use journaling, we send a CACHE FLUSH just before the writing
the commit block, and then we send a second CACHE FLUSH after writing
the commit block.  (I suppose we could use a FUA bit for the commit
block, which might be a slight optimization if there is any other
writes happening in parallel that don't need to be affected, but it
doubt it would make a huge difference in most cases.)

> e. Is the above true also for ext3 - I posted a similar question to
> ext3 forum and have got no
> response so far?

ext3 unfortunately defaults to barriers being disabled by default.
Some distributions, such as the enterprise distro's such as RHEL and
SLES, will enable ex3 barriers by default.  You can use the mount
option "barrier" to enable barriers at mount time with ext3, if you
want to be sure barriers are enabled.

With ext4, if you want to disable barriers for some reason (say you
are confident the system has a dead reliable UPS and you need the
performance), you can use the mount option nobarrier.  (It enables
barriers by default.)

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