Open chucklever opened 7 months ago
David Howells has suggested the use of filemap_splice_read instead of the older API that NFSD currently uses. That might not address the concerns in the description.
We also know that currently, not all filesystems can support iomap, so an iomap-only solution might not fly either.
Not clear whether filemap_splice_read will be sufficient for security flavors that require stable pages (currently that's krb5i and krb5p).
This was bugzilla.linux-nfs.org 398
[Chuck Lever 2022-09-12 17:44:31 UTC] Today there are two APIs that can be used to fulfill an NFS READ: one is via a splice pipe and the other is the more classic vectored read API. It's been suggested that splice reads are not as efficient as some other mechanisms (such as direct read). It's also the case that the splice read mechanism can't support the forthcoming iomap sparse read semantics. Finally, splice read cannot be used in circumstances that might require the payload to be copied: when krb5p or krb5i is in use, or when an NFSv4 READ operation is not the final operation in a COMPOUND.
It would be great to simplify the NFSD READ code paths so there was just one READ path that handles all variants of READ requests.