Re: WRITE_SAME support in FreeBSD nfsd NFSv4.1 mode?

On Sun, Jan 12, 2025 at 1:18 PM Alan Somers <asomers@freebsd.org> wrote:
>
> On Sun, Jan 12, 2025 at 12:23 AM Cedric Blancher
> <cedric.blancher@gmail.com> wrote:
> >
> > On Fri, 10 Jan 2025 at 16:02, Alan Somers <asomers@freebsd.org> wrote:
> > >
> > > On Thu, Jan 9, 2025 at 5:31 PM Dan Shelton <dan.f.shelton@gmail.com> wrote:
> > > >
> > > > Hello!
> > > >
> > > > Does FreeBSD nfsd support the WRITE_SAME request in NFSv4.1 mode?
> > > >
> > > > Dan
> > > > --
> > > > Dan Shelton - Cluster Specialist Win/Lin/Bsd
> > >
> > > Out of curiosity, what is your use case?
> >
> > As discussed in the linux-nfs@ list, is a typical "big data" and
> > database accelerator, for example fast pattern fill (1 WRITE_SAME
> > command over the write, compared to <n> commands with data block,
> > where <n> is typically > 200 average), or just zero fill for blocks.
> > It's basically reducing network traffic dramatically.
> >
> > Windows SMB 3.0 already supports that, and is a main selling point for
> > M$ to keep database people on the W$ platform. They even added several
> > Windows syscalls like
> > https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioctl-fsctl_set_zero_data
> >
> > Ced
>
> I understand why WRITE SAME would greatly reduce network traffic
> compared to writing the same data n times.  But my question is, what
> real application requires that, where the data isn't simply all-zeros?
>  Are there database operations that require writing the same non-zero
> pattern to multiple blocks?
You might find the discussion on the linux-nfs@vger.kernel.org
mailing list interesting.
It is under this subject line:
[LSF/MM/BPF TOPIC] Implementing the NFS v4.2 WRITE_SAME operation: VFS
or NFS ioctl() ?

Although there is no consensus, it seems to me that there is not a lot
of use for anything beyond zeroing blocks.
Unfortunately a WRITE_SAME implementation needs to do a lot more
that zero blocks.

I am holding off on any server implementation until there is an apparent need.

rick

>