Re: NFSv4.2 READ_PLUS support?

On Sun, Aug 24, 2025 at 6:49 PM Rob Norris <robn@despairlabs.com> wrote:
>
> On Sat, 23 Aug 2025, at 1:24 AM, Rick Macklem wrote:
> > There is a performance problem for ZFS related to holes and recently
> > written data (if vfs.zfs.dmu_offset_next_sync=1 recently created holes
> > will be found, but it really slows things down).
>
> To be clear, "recently created" here means that the record has not yet
> been written to disk, and so hasn't been through the compression stage
> in the IO pipeline yet, which is where things are turned into holes.
> dmu_offset_next_sync=1 is slow because it forces the entire transaction
> to be written down before doing the hole check. It's a very blunt
> instrument.
>
> There is some work happening to improve this situation (GH#16025[1] and
> followup[2]) that I hope to have time to assist with before the end of
> the year, so I think at least it's ok to plan for a future where ZFS is
> rather less slow at hole detection.
>
> > To get this right, it will take someone that really knows ZFS to
> > figure out how to do a VOP_READPLUS() well.
>
> I'd be happy to work on the ZFS side with a partner on the FreeBSD side.
I will think about what arguments a VOP_READPLUS() might have, but it
will be a while. (Next year is probably a reasonable timeframe.)
And, yes, I would definitely need help w.r.t. the ZFS implementation.

Fyi, Sec. 15.11.3 of RFC7862 seems to be vague on what the Seek
operation (and what a hole is). It does state...

   SEEK is an operation that allows a client to determine the location
   of the next data_content4 in a file.  It allows an implementation of
   the emerging extension to the lseek(2) function to allow clients to
   determine the next hole whilst in data or the next data whilst in
   a hole.

Which seems to indicate that it is meant to be lseek(2) compatible
and, although it was not a ratified standard when RFC7862 was
published, I think it is now a ratified POSIX standard (or will be
soon?).

rick
ps: I have never seen a statement that SEEK_DATA/SEEK_HOLE
      must find all unallocated regions in a sparse file, although I
      understand that that would be a nice feature.

>
> Cheers,
> Rob.
>
> 1. https://github.com/openzfs/zfs/pull/16025
> 2. https://github.com/openzfs/zfs/compare/master...rrevans:zfs:find_dirty