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.
