Re: Implementing VOP_READPLUS() in FreeBSD 15?

On Tue, Nov 11, 2025 at 6:40 AM Adrian Chadd <adrian@freebsd.org> wrote:
>
>
>
> 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.  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) allows
>    a server to send back to the client metadata describing the hole, and
>    DEALLOCATE (see Section 15.4) allows the client to punch holes into a
>    file.  In addition, SEEK (see 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?
Yes. Unless someone someday defines a syscall, it would only be for
the NFSv4.2 server. It could also be used by the read(2) syscall, which
could just zero out the bytes in the userspace buffer given the info that
would indicate where the hole(s) are in the byte range being read by
VOP_READPLUS().

rick

>
> Thanks,
>
>
> -adrian
>