I’d like to add something though. In my own testing, it very much looks like Samba actually utilises ZFS block-cloning in the file copy operation. Meaning the operation is instant, with no perceivable blocking delay nor I/O activity nor available space decreasing. This being the case doesn’t only change the situation wrt to the advise given by the Samba dev but of course would also be hugely beneficial to the truenas user.
When this feature is enabled on TrueNAS, it appears to use ZFS block cloning. So, yes; in a ZFS environment this might be perfectly fine for Mac clients, even if it’s not a safe defaulst for Samba itself because of how many file systems it runs on top of.
I don’t think the Samba dev team is in a position to give advice or condone use cases for specific filesystems. They can’t possibly test every Samba feature with every underlying filesystem (and every release of every underlying filesystem–ZFS gets a lot of patch releases) that Samba runs on.
I think iX would have to take on a lot more monitoring/testing work for Samba at each release if this was the default behavior for Mac clients. They’d have to decide if that’s something they’re feasibly able to do for every release at the testing stage. And realistically, it might not be.
Apple is in the best position to fix this problem permanently by redoing their SMB client implementation to behave like a a Samba client that SSC works with. Their non-standard implementation is the reason this doesn’t just work like it does for other clients.