Re: NFSv4.2 READ_PLUS support?

On Fri, 22 Aug 2025 at 15:41, Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Fri, Aug 22, 2025 at 6:31 AM Cedric Blancher
> <cedric.blancher@gmail.com> wrote:
> >
> > Good afternoon!
> >
> > Is it planned to support NFSv4.2 READ_PLUS, to optimise reading of sparse files?
> Not at this time. There is no VOP_READPLUS() vnode operation defined
> at this time.
> Without this, the NFS server must either...
> - Read all the data and then "parse out" the blobs of zeros.

No no, please no.
Holes are unallocated space. Sequences zero bytes are valid data, and
there is a difference for databases and other applications. This will
BREAK things if you suddenly add sparse file holes where no holes
were.

> or
> - Use SEEK_DATA/SEEK_HOLE. This sounds reasonable, but it currently needs
>   to be done with the vnode unlocked and dropping/re-acquiring the vnode lock
>   during a Read operation makes things awkward.
>   (The unlocked requirement is really just for other things that are done via
>     VOP_IOCTL().)
>
> Bottom line, I've missed the FreeBSD-15 deadline for adding any new
> VOP_xxx() calls and this needs one. (Either a VOP_SEEK() that can do
> SEEK_DATA/SEEK_HOLE with the vnode locked or preferably a
> VOP_READPLUS(), which can acquire data+holes in whatever is the
> most efficient way the underlying fs can do it.)

VOP_READPLUS() sounds better, because it could be hooked up into the
virtual memory management system (page file, swap file), and actually
purge VM nodes if there are no data.
Databases do that already for sparse data files - sparse file holes
mean that the B* tree will be sparse too.

Ced
-- 
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur