I have changed the code to the way rmacklem@ recommended. In fusefs we don't have to change anything as there is already a mountpoint check at the very beginning. In nfsclient I have added the mountpoint check. ZFS can handle this change without modifications.

I have updated the diff to use a kernel mount flag.

But thanks I have to track this because the same will happen for the merge from zfs-2.2-release to stable/14

Looks like jrtc27@ has already committed the lib/librt/Makefile part

When I understand this correctly, 4e8d558c9d1cf3e7e424e3fb123b01979c3d57f2 has broken poudriere? Is there an easy way how to reproduce the bug? I would like to narrow it down to a specific commit.

Use ssize_t for copy_file_range() return

Use ssize_t for copy_file_range() return

In D40898#930916, @imp wrote:

I'm kinda torn... I think we need a fallback, but I'm not 100% sure. though it is the most conservative approach and would allow people that installed a new world and then had to downgrade the kernel a chance to installworld back to an older place.

Put new code into #ifndef BOOTSTRAP_CAT

In D40882#930913, @imp wrote:

I think it's likely fine as is, but have a suggestion to make it even safer given cat's use in the build process.

In D40882#930822, @rmacklem wrote:

Btw, zfs_freebsd_copy_file_range() needs to use
vn_rlimit_fsizex() and not vn_rlimit_fsize(),
so that it copies right up to the rlimit.

I recall spotting this, but it seems to have gotten
lost in the block cloning nightmare.

Update patch

Update patch

I have updated the patch to do copy_file_range() only if no digest is requested. That makes sense so we don't read the files twice.

In D40882#930570, @asomers wrote:

LGTM. I still don't know if it's a good idea to use ZFS block-cloning, but you could take advantage of this change with, say, the NFS client. BTW, have you considered adding copy_file_range support to install(1) ?

In D40882#930509, @asomers wrote:

Could you please regenerate the diff with more context? Either use the arcanist-php82 CLI, or generate the diff with diff -U 9999.

Just simple typo fix, otherwise LGTM.

In D39419#897283, @mjg wrote:

In D39419#897277, @mm wrote:

I still don't see the benefit of the early feature check. Are mac_vnode_check_write() and vn_rlimit_fsize() expensive?
vn_generic_copy_file_range() needs to be called on unlocked vnodes

vnode locking is expensive and can be avoided with my suggestion

I still don't see the benefit of the early feature check. Are mac_vnode_check_write() and vn_rlimit_fsize() expensive?
vn_generic_copy_file_range() needs to be called on unlocked vnodes