Re: NFSv4.2 READ_PLUS support?

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.

Cheers,
Rob.

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