Re: Sparse file support in FreeBSD NFSv4.2 server

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.

> - 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.

> - 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.

> - 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.)
--> 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.

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.

rick

>
> Caveats:
> - Sparse files contain sections called "holes" which do not contain
> data, but for backwards compatibility read as 0x00 bytes. But valid
> data can contain long sequences of 0x00 bytes, which are NOT holes
> --
> Aurélien
>