From: Christoph Hellwig <hch@lst.de>
To: Christian Brauner <brauner@kernel.org>
Cc: Stefan Metzmacher <metze@samba.org>,
Christoph Hellwig <hch@lst.de>,
linux-fsdevel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
io-uring@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH] fs: add RWF_DIRECT for preadv2/pwritev2/io_uring to set IOCB_DIRECT per io
Date: Tue, 3 Nov 2026 09:07:18 +0100 [thread overview]
Message-ID: <20261103080718.GA4109@lst.de> (raw)
In-Reply-To: <20261021-kontakt-hauen-albern-9053a385d79e@brauner>
On Wed, Oct 21, 2026 at 01:04:06PM +0200, Christian Brauner wrote:
> On Mon, Oct 12, 2026 at 08:46:42PM +0200, Stefan Metzmacher wrote:
> > It's useful to control this per io request instead of using O_DIRECT
> > for the file descriptor.
>
> @Christoph thoughts on this?
Puh. This goes right into a big discussion right now. We've
traditionally said mixing buffered and direct I/O is madness, and
that's certainly not untrue. On the other hand people find this
useful - nfsd is now making heavy use of it, and a few year ago
there was a paper on how the lustre backend really gained by doing
that. So while some folks like Dave Chinner still get really angry
at the idea of mixing the modes, I feel the ship has sailed and we
need to make it work as good as possible. For some cases like
mmap'ed I/O it will always introduce data corruption, but we'd at
least make sure there's nothing exploitable. And the direct user
exposed flag would open lots of these exploit vectors.
There's also issues where file systems still check O_DIRECT for
behavior and not IOCB_DIRECT, and this would increase the problems
with that compared to the existing in-kernel only users.
NFS for example has quite a few O_DIRECT checks, and some of them
feel wrong for this.
next prev parent reply other threads:[~2026-11-03 8:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 18:46 [PATCH] fs: add RWF_DIRECT for preadv2/pwritev2/io_uring to set IOCB_DIRECT per io Stefan Metzmacher
2026-10-21 11:04 ` Christian Brauner
2026-11-03 8:07 ` Christoph Hellwig [this message]
2026-11-03 13:06 ` Stefan Metzmacher
2026-11-03 13:51 ` Paulo Alcantara
2026-11-03 19:13 ` Andy Lutomirski
2026-11-04 7:30 ` direct I/O vs buffered I/O coherency, was: " Christoph Hellwig
2026-11-04 17:48 ` Andy Lutomirski
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=20261103080718.GA4109@lst.de \
--to=hch@lst.de \
--cc=brauner@kernel.org \
--cc=io-uring@vger.kernel.org \
--cc=jack@suse.cz \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=metze@samba.org \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox