Re: Sparse file support in FreeBSD NFSv4.2 server

On Fri, May 2, 2025 at 1:39 AM Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Thu, May 1, 2025 at 3:30 PM Aurélien Couderc
> <aurelien.couderc2002@gmail.com> wrote:
> >
> > Could you please implement sparse file support in the FreeBSD NFS server?
> >
> > Typical users are databases, High Performance Computing, Big Data,
> > distributed systems and so on.
> >
> > Required are:
> > - NFSv4.2 operation "SEEK", to list sections with data, and sections with holes
> It is already there.

Thank you

>
> > - NFSv4.2 operation "ALLOCATE", to allocate disk space
> Will never happen for ZFS because it is basically impossible. I am not a ZFS
> guy, but that is what I have been told. UFS can do it, so it can be enabled if
> all your exports are UFS file systems.

Solaris has fnctl(F_ALLOCSP,...), so this should work on ZFS.

>
> > - NFSv4.2 operation "DEALLOCATE", to free/deallocate disk space, aka
> > punching a hole (which does not alter a file's size)
> Is it already there.

Merci

>
> > - NFSv4.2 operation "READPLUS", to read from sparse files. The
> > returned data are a list of unions, each union either containing the
> > block data, or the size of the hole
> > - NFSv4.2 operation "WRITESAME", to fill (and thus allocate) files
> > with repeated patterns (typical fill with zeros, or "empty pattern"
> > for databases)
> These are difficult to implement efficiently and, as such, do not provide
> any real advantage over ordinary READ/WRITE. (The simpler case of
> "writing zeros" can be done efficiently for some hardware, but that is
> not what the NFSv4.2 RFC defines.)

I disagree in the READ_PLUS case, as it benefits performance greatly,
e.g. on a 2500baseT ethernet you can read zeros from holes at around
15000MBit :)

But more seriously, it gives applications and the operating system the
"hint" that there is no data, and can act accordingly.

> --> The only advantage they provide without hardware assist is fewer
>      bytes on-the-wire, but modern networks have lots of bandwidth and
>      the overhead of doing it in software nullifies this advantage, imho.

No, callers of READ_PLUS can also act on the information that there is
no data in this place.

>
> There was a discussion on linux-nfs@vger.kernel.org which came to
> essentially the same conclusion, although they done some implementation
> of READPLUS anyhow.

Sigh, and the Linux people again came to a wrong conclusion, and now
stick to their "opinion". But that does not make them "right".

Aurélien