search

openzfsonosx / zfs

OpenZFS on OS X
https://openzfsonosx.org/
Other
822 stars 72 forks source link

Support clonefile syscall #647

Open as-com opened 6 years ago

as-com commented 6 years ago

Since ZFS is CoW, it would be appropriate to support clonefile.

Then we can finally have com.apple.mimic_apfs. 😄

Related: https://github.com/zfsonlinux/zfs/issues/405

ilovezfs commented 6 years ago

PRs welcome!

lundman commented 6 years ago

I've looked at this vnop a couple of times in the past. Simplistically, you could simply implement it by copying the file data, then the xattrs, and ACLs. You would lose the advantage of COW, but it would work. The worst comment in the manpage is:

If src names a directory, the directory hierarchy is cloned as if each item was cloned individually.

Ugh, recursive work in the kernel.

You could speed up the initial copy by changing the file into a hardlink, with a new ZFS_REFLINK flag set, and test for it at any modification place (write, truncate, extend, metadata modify), and only copy the file at that time. You then get the benefit of space saving until writes.

These are all pedestrian suggestions until such a time that openzfs pulls a rabbit out of their arses (that's the expression right?).

So far, my strategy has been to wait for Apple to deprecate the vnop and thus, profit.

Haravikk commented 4 years ago

Apologies for bumping, but I was just wondering; since ZFS supports de-duplication, isn't it just a case of leveraging the same mechanisms used for that to clone the file?

Constant, live de-duplication is costly because you need to keep a massive table of hashes in memory in order to quickly determine if a "new" block is in fact one you've seen before, but I believe that how the actual de-duplication works is relatively simple, i.e- if a block isn't new, then instead of writing it, a reference to the existing block is used instead.

In the case of a clone however we don't need de-duplication to actually be enabled (i.e- no massive in memory hash table) because we already know every block of the source file already exists, so it's simply a case of copying just the file's metadata, then pointing every block of the "new" file to point to those of the source file.

At the very least, a ZFS pool with de-duplication enabled doesn't even need specific cloning support, since it can just pretend to support it while just doing a regular copy behind the scenes (since this will be de-duplicated), but of course proper clone support would be even better since it is a less costly way of doing this (no need for a bunch of lookups).

Torsten-B commented 5 months ago

With feature@block_cloning and "zfs clonefile" coming it seems supporting clonefile(2) is possible?

lundman commented 5 months ago

Yep, enable that feature, then use cp -c on a sufficiently new macOS (Catalina and up?).

zfs clonefile might be a new command so we can cross datasets, I'll pull that in if'n it's ready.

Haravikk commented 5 months ago

on a sufficiently new macOS (Catalina and up?).

They first added APFS back in High Sierra, alongside the cp -c command and Finder support for clonefile. It's hard to believe APFS is already more than six years old (seven later this year, excluding development time)!