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@xxxxxxxxxx/ >>>> (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@xxxxxxxxxx/ > [1]: https://lore.kernel.org/linux-nfs/20250722024924.49877-8-snitzer@xxxxxxxxxx/ -- Chuck Lever
