From: Chuck Lever <chuck.lever@oracle.com>
To: Mike Snitzer <snitzer@kernel.org>
Cc: Trond Myklebust <trond.myklebust@hammerspace.com>,
Anna Schumaker <anna.schumaker@oracle.com>,
linux-nfs@vger.kernel.org, Jeff Layton <jlayton@kernel.org>
Subject: Re: [PATCH v2 0/7] NFS DIRECT: handle misaligned READ and WRITE for LOCALIO
Date: Thu, 24 Jul 2025 09:28:39 -0400 [thread overview]
Message-ID: <558b51b6-6f0d-434d-ac3c-a7989453017f@oracle.com> (raw)
In-Reply-To: <aIF14KpfHWI2239c@kernel.org>
On 7/23/25 7:53 PM, Mike Snitzer wrote:
> On Wed, Jul 23, 2025 at 02:42:56PM -0400, Chuck Lever wrote:
>> On 7/23/25 2:40 PM, Mike Snitzer wrote:
>>> On Mon, Jul 21, 2025 at 10:49:17PM -0400, Mike Snitzer wrote:
>>>> Hi,
>>>>
>>>> This "NFS DIRECT" series depends on the "NFSD DIRECT" series here:
>>>> https://lore.kernel.org/linux-nfs/20250714224216.14329-1-snitzer@kernel.org/
>>>> (for the benefit of nfsd_file_dio_alignment patch in this series)
>>>>
>>>> The first patch was posted as part of a LOCALIO revert series I posted
>>>> a week or so ago, thankfully that series isn't needed thanks to Trond
>>>> and Neil's efforts. BUT the first patch is needed, has Reviewed-by
>>>> from Jeff and Neil and is marked for stable@.
>>>>
>>>> The biggest change in v2 is the introduction of O_DIRECT misaligned
>>>> READ and WRITE handling for the benefit of LOCALIO. Please see patches
>>>> 6 and 7 for more details.
>>>
>>> Turns out that these NFS client (fs/nfs/direct.c) changes that focused
>>> on benefiting LOCALIO actually also benefit NFSD if/when it is
>>> configured to use O_DIRECT [0].
>>>
>>> Such that the NFS client's O_DIRECT code will split any misaligned
>>> WRITE IO and NFSD will then happily issue the DIO-aligned "middle" of
>>> a given misaligned WRITE IO down to the underlying filesystem.
>>>
>>> Same goes for READ, NFS client will expand the front of any misaligned
>>> READ such that the bulk of the IO becomes DIO-aligned (only the final
>>> partial tail page is misaligned).
>>>
>>> So with the NFS client changes in this series we actually don't _need_
>>> NFSD to have the same type of misaligned IO analysis and handling to
>>> expand READs or split WRITEs to be DIO-aligned. Which reduces work
>>> that NFSD needs to do by leaning on the NFS client having the
>>> capability.
>>
>> I'm not quite following. Does that apply to non-Linux NFS clients too?
>
> No, old Linux clients without these changes or non-Linux clients
> wouldn't have the capabilities offered (extending READs, splitting
> WRITEs to be DIO-aligned). The question is: do we care? Long-term:
> probably.
It sounds like we can't rely on clients to align the payload for NFSD.
So I'd say "we care".
Maybe NFSD could recognize when the content is already properly aligned
and take a shorter code path? I'm not familiar enough with your patches
yet to make a guess.
> I'd be fine with the NFSD DIRECT's misaligned IO support (READ already
> implemented/posted [0], WRITE partially implemented but not posted) to
> be land upstream so that we have the benefit of making the most of
> NFSD's O_DIRECT support even if the client doesn't take steps to issue
> IO that is DIO-aligned.
>
> Whichever way we go, it is potentially convenient that the less
> "involved" NFSD DIRECT patch 5 [0] could be withheld initially. Let
> the NFS client do the lifting for us assessing how well NFSD's
> O_DIRECT works and yet have confidence that we can deploy support for
> old Linux clients or non-Linux clients in the future by merging that
> patch 5 (and NFSD misaligned WRITE support comparable to NFS's WRITE
> splitting in this series [1]) in a secondary phase.
>
> Good to have options.
>
> Mike
>
> [0]: https://lore.kernel.org/linux-nfs/20250723154351.59042-6-snitzer@kernel.org/
> [1]: https://lore.kernel.org/linux-nfs/20250722024924.49877-8-snitzer@kernel.org/
--
Chuck Lever
next prev parent reply other threads:[~2025-07-24 13:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-22 2:49 [PATCH v2 0/7] NFS DIRECT: handle misaligned READ and WRITE for LOCALIO Mike Snitzer
2025-07-22 2:49 ` [PATCH v2 1/7] nfs/localio: avoid bouncing LOCALIO if nfs_client_is_local() Mike Snitzer
2025-07-22 2:49 ` [PATCH v2 2/7] nfs/localio: make trace_nfs_local_open_fh more useful Mike Snitzer
2025-07-22 2:49 ` [PATCH v2 3/7] nfs/localio: add nfsd_file_dio_alignment Mike Snitzer
2025-07-22 2:49 ` [PATCH v2 4/7] nfs/localio: refactor iocb initialization Mike Snitzer
2025-07-22 2:49 ` [PATCH v2 5/7] nfs/localio: fallback to NFSD for misaligned O_DIRECT READs Mike Snitzer
2025-07-22 2:49 ` [PATCH v2 6/7] nfs/direct: add misaligned READ handling Mike Snitzer
2025-07-22 2:49 ` [PATCH v2 7/7] nfs/direct: add misaligned WRITE handling Mike Snitzer
2025-07-23 18:40 ` [PATCH v2 0/7] NFS DIRECT: handle misaligned READ and WRITE for LOCALIO Mike Snitzer
2025-07-23 18:42 ` Chuck Lever
2025-07-23 23:53 ` Mike Snitzer
2025-07-23 23:58 ` Mike Snitzer
2025-07-24 13:28 ` Chuck Lever [this message]
2025-07-24 19:39 ` Mike Snitzer
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=558b51b6-6f0d-434d-ac3c-a7989453017f@oracle.com \
--to=chuck.lever@oracle.com \
--cc=anna.schumaker@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=snitzer@kernel.org \
--cc=trond.myklebust@hammerspace.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).