Re: [LSF/MM/BPF TOPIC] Implementing the NFS v4.2 WRITE_SAME operation: VFS or NFS ioctl() ?

[Jeff Layton <jlayton@kernel.org>]

On Tue, 2025-01-14 at 16:38 -0500, Anna Schumaker wrote:
> I've seen a few requests for implementing the NFS v4.2 WRITE_SAME [1] operation over the last few months [2][3] to accelerate writing patterns of data on the server, so it's been in the back of my mind for a future project. I'll need to write some code somewhere so NFS & NFSD can handle this request. I could keep any implementation internal to NFS / NFSD, but I'd like to find out if local filesystems would find this sort of feature useful and if I should put it in the VFS instead.
>
> I was thinking I could keep it simple, and model a function call based on write(3) / pwrite(3) to write some pattern N times starting at either the file's current offset or at a user-provide offset. Something like:
>     write_pattern(int filedes, const void *pattern, size_t nbytes, size_t count);
>     pwrite_pattern(int filedes, const void *pattern, size_t nbytes, size_t count, offset_t offset);
> 

These should also get flags fields, for sure.

> I could then construct a WRITE_SAME call in the NFS client using this information. This seems "good enough" to me for what people have asked for, at least as a client-side interface. It wouldn't really help the server, which would still need to do several writes in a loop to be spec-compliant with writing the pattern to an offset inside the "application data block" [4] structure.
> 
> But maybe I'm simplifying this too much, and others would find the additional application data block fields useful? Or should I keep it all inside NFS, and call it with an ioctl instead of putting it into the VFS?
> 
> Thoughts?
> Anna
> 
> [1]: https://datatracker.ietf.org/doc/html/rfc7862#section-15.12
> [2]: https://lore.kernel.org/linux-nfs/CAAvCNcByQhbxh9aq_z7GfHx+_=S8zVcr9-04zzdRVLpLbhxxSg@mail.gmail.com/
> [3]: https://lore.kernel.org/linux-nfs/CALWcw=Gg33HWRLCrj9QLXMPME=pnuZx_tE4+Pw8gwutQM4M=vw@mail.gmail.com/
> [4]: https://datatracker.ietf.org/doc/html/rfc7862#section-8.1
> 

I'd say keep it as an ioctl for now until we have at least one other
filesystem (smb/client? fs/ceph?) that can implement this natively
somehow.

My worry here is that we would build these new syscalls, and then find
that other filesystems need subtly different semantics for this, and
then we have to scramble to shoehorn those in later.

Are there are already other existing ioctls on other filesystems for
similar operations?

-- 
Jeff Layton <jlayton@kernel.org>