On Tue, Sep 8, 2026, at 11:57 PM, David Flynn wrote:
> (Sorry in advance if I’m posting this wrong in some way - little new to 
> posting here…)
>
> Totally agree that NFSD must not interpret generic -EINVAL as an 
> alignment rejection... But, a boundary check would also excludes 
> geometries that capable storage stacks could write directly. We want 
> the actual filesystem/block decision to distinguish unsupported 
> geometry from a real error, while retaining every working zero-copy 
> case.

Fair enough, but that's a filesystem-community question, outside
of NFSD's domain. If they can agree to an API contract that NFSD
can use, then I don't have a quibble.

To make your argument, of course, you will need to provide a
real-world use case with an existing in-tree filesystem or device
that can demonstrate what you need.

In the meantime, I'd like to see the narrow issue that Mike
reported addressed in the current code. Fixing the current gate
is not fraught with these deeper architectural issues, and the
fix should be backported to LTS kernels.


-- 
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)

Reply via email to