Why not backport 506fe78c48 instead?

reviewed-by: allanjude

I don't have any objection to the change, then.

I have now successfully run a FreeBSD regression test suite on a ZFS root with block cloning enabled

In D41991#958356, @mm wrote:

I have run the ZFS test suite with block cloning enabled. There are no tests with different results as when it is not enabled.

I have run the ZFS test suite with block cloning enabled. There are no tests with different results as when it is not enabled.

I have run the ZFS test suite

In D41991#957622, @mjg wrote:

for example there was panic under load when running poudriere, i don't know if that is fixed

for example there was panic under load when running poudriere, i don't know if that is fixed

@mjg Does any specific bug come to your mind?

For this to be an option this review has to provide a list of bugs reported against block cloning and commits which fix them, as is I'm not even sure it was all sorted out.

Have you tried running the test suite on a ZFS system with this change applied?

I'll added some inline comments, but they are only suggestions.
I think this minor semantics change for VOP_COPY_FILE_RANGE()
is ok, but we'll see if others disagree.

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.

Maybe I didn't make the NFS case clear.
For two different NFS mounts it can do the Copy
without reads/writes for some situations.
(Both mounts NFSv4.2 and either same server
or maybe different servers.)

As noted, I think a check for "same file system type" is needed
before a call to VOP_COPY_FILE_RANGE().

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

Committed in https://cgit.freebsd.org/src/commit/?id=c98ecfceb36159e52c8d7e5cfc0d376393a6a60b