OpenZFS on OS X

Thanks for all of the hard work that has gone into creating and maintaining this ZFS implementation for OS X! I'm having an issue upgrading from 1.4.5 (working just fine) to 1.5.2 (hangs on install), and I'm hoping to get some helpful feedback from this forum.

The target system is a Mac Pro 3.7 GHz Quad Core E5, with 128 GB RAM (OWC upgrade kit).

Upgrading from 1.4.5 to 1.5.2 follows the written guidelines (pools exported, run uninstall-complete.sh as root), and for good measure I rebooted. The installation of 1.5.2 goes smoothly until the end ("Running Package Scripts" which appears to be activating the newly installed kernel extension(s)). At this point, the installation hangs, with nothing interesting in the install.log, except a mention of ACL issue. As the installer continues to hang, I start to see "vmem waiting for 2202009600 sized alloc" - this message repeats, and is never resolved (i've waiting up to 30 minutes). This message originates within spl/spl-vmem.c, but this files hasn't changes since the 1.4.5 release (tagged 1.4.5 on Oct 18, 2015; last modified Aug 27, 2015).

I'm wondering if this has to do with changes outside of

Code: Select all

vmem_xalloc(vmem_t *vmp, size_t size, size_t align_arg, size_t phase,size_t nocross, void *minaddr, void *maxaddr, int vmflag)

itself, which would change how

Code: Select all

size_t size

parameter is calculated on machines with large RAM pool? It seems like calculations have changed (along with numerous other modifications) between 1.4.5 and 1.5.2 such that on large RAM hosts the calculated size can't/won't be allocated - but that is just speculation. I've googled around and read through these forums, but can't find anything that matches my symptoms.

Upon failed installation, I have to boot into safe mode, re-run uninstall-complete.sh, and then re-install 1.4.5 (which as I mentioned is working just fine).

Thanks for reading, and any advice

Perhaps in the interest of science you could remove some RAM to see if that is indeed the problem?

Cheers
Brendon

Science's interest is well served: I removed 2x32GB DIMMS, and when running with 64 GB installed RAM the 1.5.2 installation process flows smoothly, followed by reboot and successful `zpool import`. Sadly I need the full 128 GB RAM for statistical modeling, so I'll have to downgrade to 1.4.5 until the underlying issue with 1.5.x is resolved (I encountered the same error when installing the 1.5.1 build, but figured since it wasn't RELEASE code it would get ironed out).

Excellent, thanks. I don't think any of the developers have a machine with that much memory.

I've raised an issue to cover this https://github.com/openzfsonosx/zfs/issues/500

I haven't built SPL/ZFS from source but can take a stab with this commit and post back tomorrow. If there is a beta that I can help test on my Mac Pro please let me know.

Feel free to build from source if you can, but if you don't feel sure about it, we'll have a .pkg out "soon"

Cloned the repos yesterday and built HEAD. No issues so far: imports and pool upgrades went smoothly (running with edonr).

I just ran into this same problem on a similar configuration (Mac Pro, 128Gb ram) with the latest package. I guess my next step is to download and compile the source -- or is that considered too bleeding edge or unstable for use with production systems (and if so is the latest stable version that'll run with 128Gb of ram version 1.4.5)?

Thanks.

I've gotten spl compiled remotely over screen sharing and tried to install, but it's rejected (I'm running OS X 10.11.6). It seems that I'm going to have to disable System Integrity Protection, from within recovery mode, in order to run these kexts?

I'm guessing the kext that comes in the package was signed with a developer certificate authorized to sign kexts --is there a signed set available that includes the fix for this ram size math issue? I'd love to be able to set up a ZFS pool without having to degrade my mac's security.

Thanks for any help or info.