Re: need SUNRPC TCP to receive into aligned pages [was: Re: [PATCH 1/6] NFSD: add the ability to enable use of RWF_DONTCACHE for all IO]

[Christoph Hellwig <hch@infradead.org>]

On Fri, Jun 13, 2025 at 09:02:23AM -0400, Jeff Layton wrote:
> This is an excellent point. If the memory alignment doesn't matter,
> then maybe it's enough to just receive the same way we do today and
> just pad out to the correct blocksize in the bvec array if the data is
> unaligned vs. the blocksize.

Note that the size and the logical offset of direct I/O writes needs to
be aligned to at least the sector size of the device, and for out of
place writing file systems the block size of the file system.  It's just
the memory address that (usually) only has minimal alignment
requirements.  So no need to pad anything IFF you writes have the
right logical offset alignment and size, and if they don't, no padding
is going to help you.

> 1. nfsd could just return nfserr_inval when a write is unaligned and
> the export is set up for DIO writes. IOW, just project the requirement
> about alignment to the client. This might be the safest option, at
> least initially. Unaligned writes are pretty uncommon. Most clients
> will probably never hit the error.

Eww.  While requiring aligned writes sounds fine (the block layout
family requires it), you'll really want to come up with a draft that
allows clients to opt into it.  Something like the server offers an
attribute, that the client opts into or so.

> 2. What if we added a new "rmw_iter" operation to file_operations that
> could be used for unaligned writes? XFS (for instance) could take the
> i_rwsem exclusive, do DIO reads of the end blocks into bounce pages,
> copy in the unaligned bits at the ends of the iter, do a DIO write and
> release the lock. It'll be slow as hell, but it wouldn't be racy.

That does sound doable.  But it's a fair amount of extra VFS and file
system code, so it needs very solid numbers to back it up.