Re: NFSv4.2 READ_PLUS support?
- Reply: Cedric Blancher : "Re: NFSv4.2 READ_PLUS support?"
- Reply: Rick Macklem : "Re: NFSv4.2 READ_PLUS support?"
- In reply to: Rick Macklem : "Re: NFSv4.2 READ_PLUS support?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 22 Aug 2025 13:57:58 UTC
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.