Re: NFSv4.2 READ_PLUS support?
- In reply to: Konstantin Belousov : "Re: NFSv4.2 READ_PLUS support?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 24 Aug 2026 15:42:36 UTC
On Fri, Aug 22, 2025 at 3:58 PM Konstantin Belousov <kostikbel@gmail.com> 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 > > <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. > > 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 <aurelien.couderc2002@gmail.com> Big Data/Data mining expert, chess enthusiast