From: Mike Snitzer <snitzer@kernel.org>
To: Chuck Lever <cel@kernel.org>
Cc: Jeff Layton <jlayton@kernel.org>,
Christoph Hellwig <hch@infradead.org>,
NeilBrown <neil@brown.name>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <dai.ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
linux-nfs@vger.kernel.org, Chuck Lever <chuck.lever@oracle.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v7 14/14] NFSD: Initialize separate ki_flags
Date: Mon, 27 Oct 2025 12:18:30 -0400 [thread overview]
Message-ID: <aP-bVnJ-teH1x5eK@kernel.org> (raw)
In-Reply-To: <fc8e4689-ca7e-45e5-882f-aaa0946e1df7@kernel.org>
On Mon, Oct 27, 2025 at 09:48:23AM -0400, Chuck Lever wrote:
> On 10/27/25 6:50 AM, Jeff Layton wrote:
> > On Mon, 2025-10-27 at 01:15 -0700, Christoph Hellwig wrote:
> >> On Fri, Oct 24, 2025 at 07:56:59PM -0400, Mike Snitzer wrote:
> >>> Really, even ignoring all the quirkiness of this: that O_DIRECT can
> >>> fallback to buffered, and we need IOCB_DSYNC|IOCB_SYNC for our use of
> >>> buffered IO when NFSD_IO_DIRECT configured to ensure data has hit
> >>> stable storage -- that's enough justification. Bit circular but
> >>> compelling to prove the need.. albeit wordy and a lot to unpack.
> >> You always need IOCB_DSYNC for data to hit stable storage, both for
> >> buffered and direct I/O. You need IOCB_SYNC in addition to also sync
> >> out the timestamps, which I think we now agree we need. I still don't
> >> understand why using direct I/O implies that we want NFS stable writes
> >> and not two-stage writes, though.
> > That's certainly a possibility too. Consider the case where we have a
> > WRITE with unaligned parts at both ends. This set so far just does the
> > ends as synchronous I/Os.
> >
> > We could do the end bits as non-synchronous writes, and follow up with
> > a vfs_fsync_range() call before returning NFS_FILE_SYNC.
>
> What concerns me a bit is that the code that handles unaligned ends
> is careful to issue the vfs_iocb_iter_writes in file offset order. Are
> we OK to use IOCB_DSYNC for the unaligned parts but IOCB_DIRECT +
> subsequent COMMIT for the direct I/O middle segment?
LOCALIO's misaligned DIO will issue head/tail followed by O_DIRECT
middle (via AIO completion of that aligned middle). So out of order
relative to file offset.
That has been working well with LOCALIO.. though I did just post a
patchset today that fixes some quirks of the implementation that got
flagged for KASAN use-after-free.
(But now that I look at LOCALIO misaligned DIO code, it actually isn't
even setting IOCB_DSYNC for the misaligned head/tail... needs fixing.)
next prev parent reply other threads:[~2025-10-27 16:18 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 14:42 [PATCH v7 00/14] NFSD: Implement NFSD_IO_DIRECT for NFS WRITE Chuck Lever
2025-10-24 14:42 ` [PATCH v7 01/14] NFSD: Make FILE_SYNC WRITEs comply with spec Chuck Lever
2025-10-24 15:21 ` Jeff Layton
2025-10-27 8:02 ` Christoph Hellwig
2025-10-24 14:42 ` [PATCH v7 02/14] NFSD: Enable return of an updated stable_how to NFS clients Chuck Lever
2025-10-27 8:03 ` Christoph Hellwig
2025-10-24 14:42 ` [PATCH v7 03/14] NFSD: Refactor nfsd_vfs_write() Chuck Lever
2025-10-27 8:04 ` Christoph Hellwig
2025-10-24 14:42 ` [PATCH v7 04/14] NFSD: Implement NFSD_IO_DIRECT for NFS WRITE Chuck Lever
2025-10-24 17:12 ` Mike Snitzer
2025-10-24 17:24 ` Chuck Lever
2025-10-26 0:03 ` kernel test robot
2025-10-26 1:16 ` kernel test robot
2025-10-24 14:42 ` [PATCH v7 05/14] NFSD: @stable for direct writes is always NFS_FILE_SYNC Chuck Lever
2025-10-24 15:22 ` Jeff Layton
2025-10-24 15:23 ` Chuck Lever
2025-10-27 8:05 ` Christoph Hellwig
2025-10-27 13:23 ` Chuck Lever
2025-10-27 13:27 ` Christoph Hellwig
2025-10-27 14:31 ` Mike Snitzer
2025-10-27 14:36 ` Christoph Hellwig
2025-10-27 14:58 ` Mike Snitzer
2025-10-27 15:04 ` Chuck Lever
2025-10-27 15:19 ` Mike Snitzer
2025-10-27 15:05 ` Christoph Hellwig
2025-10-24 14:42 ` [PATCH v7 06/14] NFSD: Always set IOCB_SYNC in direct write path Chuck Lever
2025-10-24 15:22 ` Jeff Layton
2025-10-27 8:08 ` Christoph Hellwig
2025-10-27 10:38 ` Jeff Layton
2025-10-27 10:40 ` Christoph Hellwig
2025-10-24 14:42 ` [PATCH v7 07/14] NFSD: Remove specific error handling Chuck Lever
2025-10-24 15:22 ` Jeff Layton
2025-10-24 14:43 ` [PATCH v7 08/14] NFSD: Remove alignment size checking Chuck Lever
2025-10-24 15:22 ` Jeff Layton
2025-10-27 8:09 ` Christoph Hellwig
2025-10-27 13:25 ` Chuck Lever
2025-10-27 13:30 ` Christoph Hellwig
2025-10-24 14:43 ` [PATCH v7 09/14] NFSD: Remove the len_mask check Chuck Lever
2025-10-24 15:23 ` Jeff Layton
2025-10-24 17:16 ` Mike Snitzer
2025-10-24 17:22 ` Chuck Lever
2025-10-24 14:43 ` [PATCH v7 10/14] NFSD: Clean up synopsis of nfsd_iov_iter_aligned_bvec() Chuck Lever
2025-10-24 15:24 ` Jeff Layton
2025-10-24 14:43 ` [PATCH v7 11/14] NFSD: Clean up struct nfsd_write_dio Chuck Lever
2025-10-24 15:26 ` Jeff Layton
2025-10-24 17:20 ` Mike Snitzer
2025-10-24 14:43 ` [PATCH v7 12/14] NFSD: Introduce struct nfsd_write_dio_seg Chuck Lever
2025-10-24 15:30 ` Jeff Layton
2025-10-24 15:37 ` Chuck Lever
2025-10-24 17:57 ` Mike Snitzer
2025-10-24 14:43 ` [PATCH v7 13/14] NFSD: Clean up direct write fall back error flow Chuck Lever
2025-10-24 15:32 ` Jeff Layton
2025-10-24 18:01 ` Mike Snitzer
2025-10-24 14:43 ` [PATCH v7 14/14] NFSD: Initialize separate ki_flags Chuck Lever
2025-10-24 15:34 ` Jeff Layton
2025-10-24 18:13 ` Mike Snitzer
2025-10-24 19:34 ` Chuck Lever
2025-10-24 20:37 ` Mike Snitzer
2025-10-24 21:16 ` Chuck Lever
2025-10-24 23:56 ` Mike Snitzer
2025-10-27 8:15 ` Christoph Hellwig
2025-10-27 10:50 ` Jeff Layton
2025-10-27 10:55 ` Christoph Hellwig
2025-10-27 13:48 ` Chuck Lever
2025-10-27 13:49 ` Christoph Hellwig
2025-10-27 16:18 ` Mike Snitzer [this message]
2025-10-27 16:59 ` Mike Snitzer
2025-10-29 7:20 ` Christoph Hellwig
2025-10-27 16:05 ` Mike Snitzer
2025-10-27 17:57 ` Chuck Lever
2025-10-28 3:26 ` Mike Snitzer
2025-10-28 15:37 ` Chuck Lever
2025-10-28 16:04 ` Mike Snitzer
2025-10-28 18:48 ` Chuck Lever
2025-10-28 23:56 ` Mike Snitzer
2025-10-29 15:22 ` Chuck Lever
2025-10-29 16:54 ` Mike Snitzer
2025-10-29 7:37 ` Christoph Hellwig
2025-10-29 7:32 ` Christoph Hellwig
2025-10-29 7:25 ` Christoph Hellwig
2025-10-27 8:14 ` Christoph Hellwig
2025-10-27 8:12 ` Christoph Hellwig
2025-10-27 13:27 ` Chuck Lever
2025-10-27 13:30 ` Chuck Lever
2025-10-27 13:31 ` Christoph Hellwig
2025-10-27 14:11 ` Chuck Lever
2025-10-27 14:45 ` 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=aP-bVnJ-teH1x5eK@kernel.org \
--to=snitzer@kernel.org \
--cc=cel@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=tom@talpey.com \
/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.