linux-ext4 - Re: Writing more than 4096 bytes with O_SYNC flag does not persist all previously written data if system crashes

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

Message-ID: <20260219133244.GB69183@macsyma-wired.lan>
Date: Thu, 19 Feb 2026 08:32:44 -0500
From: "Theodore Tso" <tytso@....edu>
To: Andreas Dilger <adilger@...ger.ca>
Cc: Vyacheslav Kovalevsky <slava.kovalevskiy.2014@...il.com>,
        linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-man@...r.kernel.org
Subject: Re: Writing more than 4096 bytes with O_SYNC flag does not persist
 all previously written data if system crashes

+linux-man

On Wed, Feb 18, 2026 at 02:55:13PM -0700, Andreas Dilger wrote:
> If anything, the man page should be updated to be more concise, like:
> 
>     "the *just written* output data *on that file descriptor* and associated
>      file metadata have been transferred to the underlying hardware (i.e.
>      as though each write(2) was followed by a call to sync_file_range(2)
>      for the corresponding file offset(s))"

Yeah, this is an inaccuracy in the man page; the definition of O_SYNC
from the Single Unix Specification states:

    O_SYNC    Write I/O operations on the file descriptor shall complete
                                   ^^^^^^^^^^^^^^^^^^^^^^
              as defined by synchronized I/O file integrity completion.

Compare and contrast this to what's in the Linux manpage:

       O_SYNC Write  operations  on the file will complete according to the re‐
              quirements of synchronized I/O file integrity completion (by con‐
              trast with the synchronized I/O data  integrity  completion  pro‐
              vided by O_DSYNC.)

              By  the  time  write(2) (or similar) returns, the output data and
              associated file metadata have been transferred to the  underlying
              hardware (i.e., as though each write(2) was followed by a call to
              fsync(2)).  See VERSIONS.

The parenthetical comment in the second paragraph needs to be removed,
since fsync specifices that all dirty information in the page cache
will be flushed out.  From the fsync man page:

       fsync() transfers ("flushes") all modified in-core data of (i.e.,  modi‐
       fied buffer cache pages for) the file referred to by the file descriptor
       fd  to  the  disk device (or other permanent storage device) so that all
       changed information can be retrieved even if the system  crashes  or  is
       rebooted.   This  includes  writing  through or flushing a disk cache if
       present.  The call blocks until the device reports that the transfer has
       completed.

I'll also mention that the fsync man page doesn't really talk about
its interaction with O_DIRECT writes.  This is mentioned in the
open(2) man page, and in general, people who use O_DIRECT are
generally expected to know what they are doing.  But in the context of
O_DIRECT writes, the fsync(2) call is also used to make sure that a
CACHE FLUSH or equivalent command is sent to the storage device, such
that the O_DIRECT write is guaranteed to persist after a power
failure.

Cheers,

					- Ted