Re: Implementing VOP_READPLUS() in FreeBSD 15?

On Thu, 6 Nov 2025 at 18:02, Rick Macklem <rick.macklem@gmail.com> wrote:


> If VOP_READPLUS() is done, but there is no readplus(2) syscall, then the
> applications still get globs of 0s in the read(2) reply (assuming the
> application
> doesn't bother to use lseek(SEEK_DATA/SEEK_HOLE) to skip over the
> holes in a sparse file).
> --> Even if FreeBSD were to "go out on a limb" and implement a
>      readplus(2) syscall, who would use it. (Not anyone implementing
>      a POSIX compliant application nor anyone implementing a Linux
>      application.)
>      --> Until Linux does some syscall like readplus(2) someday maybe
>            I still question how useful VOP_READPLUS() is even if it has
>            fs specific implementations.
>
> At least that's how I see it, rick
>
>
if i read it correctly though, it means they're also reducing memory
pressure and VM updates
with lots of mappings of a single zero page.

I also did a bit of digging, and it looks like read_plus is from an NFS
v4.2 RFC (rfc7862), which
makes the request actually make more sense.

1.4.3 <https://www.rfc-editor.org/rfc/rfc7862#section-1.4.3>.  Sparse Files

   Sparse files are files that have unallocated or uninitialized data
   blocks as holes in the file.  Such holes are typically transferred as
   zeros when read from the file.  READ_PLUS (see Section 15.10
<https://www.rfc-editor.org/rfc/rfc7862#section-15.10>) allows
   a server to send back to the client metadata describing the hole, and
   DEALLOCATE (see Section 15.4
<https://www.rfc-editor.org/rfc/rfc7862#section-15.4>) allows the
client to punch holes into a
   file.  In addition, SEEK (see Section 15.11
<https://www.rfc-editor.org/rfc/rfc7862#section-15.11>) is provided to
scan for
   the next hole or data from a given location.


So it sounds like they're actually requesting more NFS v4.2 stuff, and the
VOP request
would just be the support of that?

Thanks,


-adrian