Re: NFSv4.2 READ_PLUS support?

On Mon, 25 Aug 2025, at 12:20 PM, Rick Macklem wrote:
> Btw, here's the background to how I found out about
> dmu_offset_next_sync. Garrett Wollman runs a bunch (around 20?)
> FreeBSD NFS servers using ZFS at MIT (at least he did last I heard
> from him).  He noticed some copy_file_range() { called Copy in NFSv4.2
> } were taking a long time (one case was 25sec).  I (maybe mistakenly)
> implemented copy_file_range(2) to try and maintain sparseness when
> copying large files by using SEEK_DATA/SEEK_HOLE, which was causing
> the slow copying. (He found that setting dmu_offset_next_sync=0 fixed
> the problem for him.) In this case, that is no problem, since
> copy_file_range(2) on FreeBSD tries to maintain sparseness, but does
> not guarantee to do so.

Yeah, that makes sense. I remember being both surprised and impressed to
see FreeBSD's copy_file_range() try to preserve holes. There's nothing
that says it shouldn't; by definition it is free to copy the file
however it wishes. Linux doesn't do it in its fallback path though,
leaving it to the application (eg coreutils) to coordinate if it wants
it. And that's why the tuneable has a different impact between the two
systems, because its more likely to affect "incidental" uses on FreeBSD.

Cheers,
Rob.