OpenZFS on OS X

I took the new public beta for a short spin this morning. No immediate problems evident with OpenZFS_on_OS_X_1.3.1-RC5. However, Photos refuses to recognise my iPhoto libraries on a zfs filesystem, reports an unsupported disk format. I've filed feedback and hope that this won't be the case with the final software. I've had bit rot in my photo files previously, I don't want to go back to that problem!

Did you try with a filesystem with the casesensitivity setting to insensitive?

Hi,

If you are able to install from source (https://openzfsonosx.org/wiki/Install#I ... from_sourc[list=][/list]e), master has a new property "com.apple.mimic_hfs", that when enabled causes ZFS filesystems to identify themselves as HFS.

Would you be able to try this and report back?

Its known to work for OSX Server, and iMovie.

- Brendon

Hi - to answer vmv's question, yes, I was running on a case insensitive file system. I'll give the source install a try, may not be able to until Wednesday however. I'll let you know the results.

Well, good news. Found time to do the install from source this afternoon. Set the com.apple.mimic_hfs property to on. I can confirm that it works with OS X Server, which was a good start. With Photos beta I got the following error message: Repair Library Permissions: This photo library is locked or you do not have permissions to make changes to it. Photos can try to repair the permissions. So I backed out, duplicated the iPhoto library I was testing on, and tried again. When I allowed Photos to run the permissions repair, it did so satisfactorily. The library is able to be opened in both Photos and iPhoto, which is the correct behaviour as far as I know. I tested library creation in the zfs filesystem, that worked OK, and I also tested setting the System Photos Library to one in the zfs filesystem, which also worked.
I presume the com.apple.mimic_hfs property remains set between reboots. Are there any downsides to setting it as on for all zfs filesystems, if, as I am, you are only using Mac OS X with your pool?
Thanks for the help, great to get it working.

It should be fine. Other platforms will just ignore the property anyway. The only issues would be the converse - if there's something explicitly checking for a hard-coded "zfs" and it's now reporting "hfs." For example, in the output of /sbin/mount you will see something like

Code: Select all

internal/vms on /Volumes/internal/vms (hfs, local, noatime)


rather than

Code: Select all

internal/vms on /Volumes/internal/vms (zfs, local, noatime)


This conflicts with https://github.com/ilovezfs/openzfsonos ... olcheck.sh which explicitly checks for "zfs" in that output. So I will have to consider revising the script in some way to support the case where mimic_hfs=on.

FadingIntoBlue wrote:Well, good news. Found time to do the install from source this afternoon.

Given that you just went through the install-from-source instructions and procedure, I'm curious whether you ran into any inaccuracies, points of friction, or unclear steps.

Given that you just went through the install-from-source instructions and procedure, I'm curious whether you ran into any inaccuracies, points of friction, or unclear steps.

No problems at all. I had done an install from source back with OS X 10.9, the instructions and flow seemed a little more straightforward, but then last time I pieced the instructions together from references to several sites. The only unnecessary deviation was where I downloaded zfsadm from the place referenced in the instructions, then realised that I didn't need to as the next set of terminal commands did it anyway. Got the set of warnings referred to later on, but no errors, again, similar to what happened under 10.9. I was expecting it all to take longer, as it did the previous time.

One thing worth adding on to the end, might be that a sudo pool import -f or import poolname(s) would save a little worry for those who can't find their pools after installing from source. I expected an automatic mount, when I connected the drives but that didn't happen.

So overall comment, a simple straightforward process, which a neophyte to the command line should be able to follow without undue risk.

Thanks for the thoughtful response.

Currently, zfs.util, which is responsible for importing pools automatically when they're not connected during boot, will (deliberately) only import pools that are in the zpool.cache file, to which zed adds pools upon import and from which zed removes pools upon export. Given that InvariantDisks is now in master, we shall be considering re-expanding zfs.util's scope to include pools that are both not connected during boot and not in the zpool.cache file. One question there would be, if zfs.util's scope is expanded, do we want it to import or to import -f; in other words, should pools last imported and/or exported on a different system be included or not within zfs.util's scope?

I'd rather not see too much auto-magic things. I sometimes export a pool for some reason (hardware issues, benchmarking, ...) and then I want it to stay exported, even after reboot.

ilovezfs wrote:... re-expanding zfs.util's scope to include pools that are both not connected during boot and not in the zpool.cache file. One question there would be, if zfs.util's scope is expanded, do we want it to import or to import -f; in other words, should pools last imported and/or exported on a different system be included or not within zfs.util's scope?

If I hook up a zpool from another system, I defintly want to be in control of the process and not have it auto-mounted.

Maybe something like the pop-up from Finder when there is an unknown device (Format, Eject or Ignore). That would be OK and also in line with current practice on a Mac