Re: NFSv4.2 READ_PLUS support?

On Fri, Aug 22, 2025 at 3:58 PM Konstantin Belousov <[email protected]> wrote:
>
> On Fri, Aug 22, 2025 at 06:41:23AM -0700, Rick Macklem wrote:
> > On Fri, Aug 22, 2025 at 6:31 AM Cedric Blancher
> > <[email protected]> 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.
> > 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.)
> >
> > So, maybe for FreeBSD-16, but not yet, rick
>
> We certainly can add a new VOP to stable, this should not be a problem.
> First, we have spare VOPs in the vop vtable.
> Second, we do not guarantee KBI stability for VFS.  We try to provide it,
> but not too hard.  If there are benefits like that, KBI can be broken: we
> did it many times already.

What about the READ_PLUS VOB proposal?

Aurélien
-- 
Aurélien Couderc <[email protected]>
Big Data/Data mining expert, chess enthusiast