Various work on OpenZFS and ZFS/FreeBSD.
Details
Jan 24 2025
Oct 11 2024
Jun 24 2024
Jun 21 2024
Jun 20 2024
I guess the change for sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.c go to upstream first. Will it ?
I would subtly change the title :-)
Otherwise, looks good to me.
Jun 19 2024
May 22 2024
May 20 2024
Mar 18 2024
Why not backport 506fe78c48 instead?
Mar 5 2024
Feb 27 2024
reviewed-by: allanjude
Feb 23 2024
Nov 27 2023
Oct 14 2023
Oct 10 2023
I don't have any objection to the change, then.
Sep 30 2023
I have now successfully run a FreeBSD regression test suite on a ZFS root with block cloning enabled
Sep 29 2023
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
Sep 27 2023
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?
Sep 6 2023
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.
Sep 5 2023
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.