All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Theodore Tso <tytso@mit.edu>
Cc: Andreas Dilger <adilger@dilger.ca>,
	 Vyacheslav Kovalevsky <slava.kovalevskiy.2014@gmail.com>,
	linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
	 linux-man@vger.kernel.org
Subject: Re: Writing more than 4096 bytes with O_SYNC flag does not persist all previously written data if system crashes
Date: Mon, 23 Feb 2026 13:46:54 +0100	[thread overview]
Message-ID: <aZxLxum4WFYKbx2O@devuan> (raw)
In-Reply-To: <20260219133244.GB69183@macsyma-wired.lan>

[-- Attachment #1: Type: text/plain, Size: 3156 bytes --]

Hi Ted, Andreas,

On 2026-02-19T08:32:44-0500, Theodore Tso wrote:
> +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.

Would you mind checking the text in VERSIONS (since there's a reference
to it right next to the text you're proposing to remove)?  I suspect it
will also need to be updated accordingly.  I don't feel qualified to
touch that text by myself.

If you'd write a patch, I'd appreciate that.


Have a lovely day!
Alex

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

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-02-23 12:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-18 13:29 Writing more than 4096 bytes with O_SYNC flag does not persist all previously written data if system crashes Vyacheslav Kovalevsky
2026-02-18 21:55 ` Andreas Dilger
2026-02-19 13:32   ` Theodore Tso
2026-02-23 12:46     ` Alejandro Colomar [this message]
2026-02-23 19:32       ` Theodore Tso
2026-02-24  1:21         ` Andreas Dilger
2026-03-03 13:19         ` Alejandro Colomar
2026-02-24 14:47 ` Christoph Hellwig
2026-02-24 22:23   ` Darrick J. Wong
2026-02-25 14:20     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aZxLxum4WFYKbx2O@devuan \
    --to=alx@kernel.org \
    --cc=adilger@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=slava.kovalevskiy.2014@gmail.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.