Ticket #5082: add file cloning support for FreeBSD, Solaris and macOS

[tuffnatty]

Proposed changes

Use copy_file_range(2) on FreeBSD for file cloning.

It should resolve #5082 and probably #4991. copy_file_range(2) also supports remote NFS operations, but it's out of scope for this change.

• Resolves: File clone VFS operation support on FreeBSD #5082
• Resolves: File move on ZFS TrueNAS #4991

While we're at it, also add support for clonefile(2) on macOS and reflink(3C) on Oracle Solaris.

The patch also adds support for cloning in Append/Reget modes. This is working only in Linux and FreeBSD and only if the filesystem allows it (e.g. the start offsets must be block-aligned).

As file cloning is not always a desired thing, a new configuration option is introduced to disable it.

Checklist

👉 Our coding style can be found here: https://midnight-commander.org/coding-style/ 👈

• I have referenced the issue(s) resolved by this PR (if any)
• I have signed-off my contribution with git commit --amend -s
• Lint and unit tests pass locally with my changes (make indent && make check)
• I have added tests that prove my fix is effective or that my feature works
• I have added the necessary documentation (if appropriate)

I have not added any tests for the feature, as it would involve actions fairly complicated from the ops point of view (like, create a test ZFS filesystem), and the test infrastructure does not offer any support for superuser/VM operations. But it's working locally, copy/move within one ZFS pool became instant, and the existing tests pass.

[zyv]

Wow, is it possible to test it in some way? As you can see, we now have CI on FreeBSD. Maybe some way to check that copy_file_range indeed gets called?

[tuffnatty]

I've added a very dumb test that seems to work on Linux as well as on FreeBSD.

[zyv]

I've added a very dumb test that seems to work on Linux as well as on FreeBSD.

To me that looks fantastic, but can't you check that ENOTSUP is returned on other platforms? We have also CI that runs on Solaris and macOS. This way, all possibilities will be covered. Thank you!

[tuffnatty]

Hi. It took a bit of time... The new pull request adds macOS and Oracle Solaris support as well. On these platforms, the syscalls for file cloning respond for destination file creation, that is, they take in a path instead of a file descriptor, so the logic around the copy operation had to be adapted.
So the test tests if both kinds of mocked syscalls are called with proper arguments, and that on unsupported platforms, ENOTSUP is returned.
Also, the patch introduces a new user configuration option to enable or disable COW file cloning, as it is not always a desired kind of operation. This part of the pull request depends on #5087 to be merged first.

[zyv]

Wow, this really looks fantastic. I'm much impressed. I wonder what the others think. I have but just a few minor comments.

[tuffnatty]

I've added support for file cloning in append/reget modes. It's working on FreeBSD and Linux when the file offsets are block-aligned. I've also removed the extra #ifs by moving the corresponding checks to autoconf.

[tuffnatty]

The linter fails because I have touched a file with pre-existing invalid formatting.

[zyv]

I've added support for file cloning in append/reget modes. It's working on FreeBSD and Linux when the file offsets are block-aligned. I've also removed the extra #ifs by moving the corresponding checks to autoconf.

This looks good to me! I'm just left wondering whether this is a good idea to enable it by default.

Are you planning to do anything else in this PR, or are you considering it ready for review now?

[tuffnatty]

I had to find and click the Submit review button as my previous review comments were in pending state.

I don't think I have anything to add or remove at this moment.

[zyv]

I've fixed the formatting error by adding a few hanging commas (in the same commit). Inasmuch as I'm concerned, this looks ready for merge. Thank you for your high-quality contribution! 👍

[tuffnatty]

Thanks @zyv!

[tuffnatty]

I've updated the pull request with man page updates; unfortunately, the localized man pages were partially outdated, so I had to fix that, and now the PR depends on #5093, #5095, #5096, #5097, #5098, #5099. My Hungarian is definitely not at the level where I could fix the Hungarian man page as well, so I had to keep it as-is.

[zyv]

Could you please rebase and resolve the conflicts? Thank you!

[tuffnatty]

I've rebased the PR against master and updated the description above to match the actual content.