OpenZFS on OS X

roemer wrote:Thanks for the link. So the rationale is pool-compatibility with Linux/Solaris.
In that discussion thread on Github, you pointed to the 'xattr_darwinacls' branch as potential alternative.
That branch was last modified about 4 months ago.
How is that branch kept up-to-date with bugfixes in the master branch?

Secondly, if I compile my own kernel extension from that branch, it is not signed and would hence create a warning at each boot from OS X 10.9?
Anyway to avoid this (other than paying 99 bucks/anno to Apple

That branch would need to be rebased off of master. However, although I put that branch out there to appease those who are bothered by this, I do not particularly like that method. A "correct" method would implement an entirely separate ACL type for Darwin ACLs. Basically we'd need to spoof Darwin ACLs which are meant to only be "extras" above and beyond the mode, which is not entirely possible since Darwin ACLs can create situations that NFSv4 ACLs cannot, or we'd need to introduce a pool incompatibility, with a feature flag, or later, when there is OpenZFS support for it, a per dataset flag.

In my opinion, a separate Darwin ACL type is an extremely low priority item.

The best discussion of the difference between Darwin ACLs and NFSv4 ACLs is here:
https://wiki.freebsd.org/NFSv4_ACLs
___
When it's your own kext, compiled by you and unsigned, it should be installed to /System/Library/Extensions instead of /Library/Extensions, which is reserved for signed kexts. You only get that warning once and then it gets white-listed.

Thanks for the response. I also found git's rebase command in the meanwhile, but as it prompts for manual action to fix clashes on zfs_acl.c, I tested with the original 'xattr_darwinacls' branch. I actually like its effect: In my (few) tests so far, zfs did preserve Mac ACLs correctly, even after a full round-trip HFS+ - ZFS - HFS+. I like this, as it gives me - from the user perspective - the confidence that the file system retains my data, including its metadata and permissions. As far as I can see, the intermediate usage of extended attributes to store the ACLs is kept hidden from users.

I understand that this is additional implementation work and hassle when trying to keep full pool compatibility with OpenZFS.
But as a file system user, I appreciate to be able to trust a system, even for features which I myself might not need every day.
Given that I anticipate only few ACLs making it into my ZFS pool, typically in form of application bundles as part of my SoftwareArchive, I am happy to pay the storage overhead of extended attributes for mapping those ACLs. Anything else what speaks again using the xattr_darwinacls' branch approach?
___
Re the manually compiled kext: Yep, will keep it in /System/Library/Extensions then - though it feels like a strange place for user-compiled code
The more I would appreciate support for this branch in an official release of O3X.

I understand your desire. Nonetheless, this branch will almost certainly not receive any support going forward and may be deleted.

Actually a pitty - I just ran the 'backup bouncer' test again between HFS+ and a zfs pool under a (now correctly rebased) 'xattr_darwinacls' branch. I used rsync (-aNHAXx --fileflag), and the result looks quite promising now:

Code: Select all

Verifying:    basic-permissions ... ok (Critical)
Verifying:           timestamps ... ok (Critical)
Verifying:             symlinks ... ok (Critical)
Verifying:    symlink-ownership ... ok
Verifying:            hardlinks ... ok (Important)
Verifying:       resource-forks ... ok (Critical)
Verifying:         finder-flags ... ok (Critical)
Verifying:         finder-locks ... ok
Verifying:        creation-date ... FAIL                           (creation date is always set to system timestamp?)
Verifying:            bsd-flags ... ok
Verifying:       extended-attrs ... ok (Important)
Verifying: access-control-lists ... ok (Important)
Verifying:                 fifo ... ok
Verifying:              devices ... ok
Verifying:          combo-tests ... ok

The additional FinderFlags, which I reported in my initial post, are not there when using rsync. Seems to be something specific to the way ChronoSync makes its copies. Extended attributes, resource forks, flags, permissions, acls all seem fine, and stay fine once I do a round-trip with rsync back to HFS+ again.

But why is the creation date not maintained? Is this a side-effect of 'atime=off' or do I miss something else?

The "Date Created" thing may be a bug, and is unrelated to the atime property. Although the "Date Added" is stored in Spotlight, "Date Created" is not, so if we are in fact always returning system time or something for "Date Created" that is wrong.

I will reiterate again that we need to move on from this ACLs obsession.

Actual project priorities you should be obsessing about (to fill the void): https://openzfsonosx.org/wiki/Project_roadmap

And as you can see, it does not even mention the GUI.

It is entirely possible we do not do the creation dates correctly, I have not looked too deeply into those glue functions. OSX also has more date related fields than ZFS (upstream) store, so in some places, the dates have been approximated.

Created an issue for this:
https://github.com/openzfsonosx/zfs/issues/147

ilovezfs wrote:Created an issue for this:
https://github.com/openzfsonosx/zfs/issues/147

Many thanks!
The latest release (v1.2.7) seems indeed to correctly copy the creation-dates.


For the moment, I will keep using the (re-based) 'xattr_darwinacls' branch though as these default ACLs are still there...