#51246 closed submission (wontfix)
submission: port:zfs and port:zfs-devel
Reported by: | RJVB (René Bertin) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | ||
Port: |
Description
I've finally gotten around to making a port for the OS X implementation of the ZFS filesystem, now that it seems to have reached a sufficient maturity (read: it no longer causes system instability after having done a few simple tests).
I don't think I have to introduce ZFS here, but for those who really don't know what it is: It's the filesystem that Apple once considered as an officially supported FS, if not the default for OS X. It provides very high data reliability (*), is extremely flexible & scalable and has a potential for very good performance (though not necessarily trivial and probably not yet in the OS X implementation). It also offers optional on-the-fly compression including using the lz4 scheme which is fast enough to improve I/O to slow media (time spent de/compressing is less than the increase in data transfer times).
*) even when using a single partition because it can write each file in multiple copies - a feature that prevented me from losing no more than a single trivial file from my Linux rig when a disk started dropping sectors on me at a rate I never saw before a few days ago.
I already tested an earlier release from an officialy installer on Bradley's (pixilla) VM about a year ago, using it to put a whole MacPorts install in a dataset mounted on /opt/local, with compression, case sensitivity and redundancy for important parts like the registry.
The current implementation installs everything properly into ${prefix}, kernel extensions included. That works fine on OS X 10.9 (with a single warning when loading eacho of the kexts the 1st time).
I'd be very interested in feedback from users on more recent versions of OS X, notably 10.11 . I suspect it might be necessary to put the kernel stuff into /Library when SIP is not disabled (?)
Notes:
- ZFS does tend to like having sufficient memory. On systems with <8Gb it might be wise to read up on reducing the max. amount used by ARC (not related to ObjC's ARC ;))
- This is a project that's seeing active development and continuous improvement. There's a
port:zfs
but I would strongly suggest to testport:zfs-devel
. - In fact, I'd (almost) suggest to use an official installer from the project's website instead of using
port:zfs
, because that should give better system integration "out of the box". On the other hand, the MacPorts version should be less intrusive/invasive and easier to uninstall.
WARNING: This port installs kernel extensions which get loaded automatically when using ZFS. As a result it should PROBABLY NOT be deactivated, uninstalled or reinstalled without taking the following precautions: 1) unmount (export) all ZFS datasets and pools 2) kextunload zfs.kext 3) kextunload spl.kext
Question: is there a phase where one could check if either of the kexts is loaded, and raise an error if that is the case (pre-deactivate would be perfect)?
Attachments (6)
Change History (17)
comment:1 Changed 9 years ago by RJVB (René Bertin)
comment:2 Changed 9 years ago by RJVB (René Bertin)
comment:3 Changed 9 years ago by ilovezfs@…
Hi MacPorts administrators, OpenZFS on OS X project here. We'd prefer that this not be part of MacPorts at this time. Thank you.
comment:4 Changed 9 years ago by RJVB (René Bertin)
Explanation for this request from a single upstream dev who may or may not be voicing the majority opinion: SIP.
In other words, that concerns only 10.11, and it should be perfectly possible to find a way around this, like reaping the kexts off an upstream DMG in the non-devel port , or a co-maintainer with the possibility to sign the kexts (on the 10.11+ buildbots). Edit 2 : OSXFuse also snatches the to-be-signed bits from an official installer.
I don't think this kind of port will mean much to most users who are better off with SIP. Users who are interested in a -devel port are IMHO much more likely to know the potential risks of running without that additional safety net (= in a pre-SIP configuration).
I was hoping to get a little bit more appreciation for introducing a wider audience to the ZFS effort. Edit: instead:
[20160427 16:41] *** ChanServ gives channel operator privileges to ilovezfs_. [20160427 16:41] *** ilovezfs_ sets a ban on rjvb!*@*. [20160427 16:41] *** ChanServ takes channel operator privileges from ilovezfs_. [20160427 16:42] <rjvb> very mature ... [20160427 16:42] *** ChanServ gives channel operator privileges to ilovezfs_. [20160427 16:43] *** You have been kicked from channel #openzfs-osx by ilovezfs_ (rjvb).
Anyway, maybe this ticket alone will have that effect, ZFS is too useful to let it the a single person's (or select group's) plaything.
comment:5 Changed 9 years ago by RJVB (René Bertin)
I've followed port:osxfuse
's lead to make some changes for political correctness:
port:zfs
has been downgraded so it can use the official 1.4.5 installer to redistribute the signed kexts on 10.10 and beyond. I think it's acceptable to subject the user to a one-time warning about loading unsigned kexts on 10.9 so as to use truly matching kexts on that version, but everything is ready to use the signed kexts on that platform too.
port:zfs-devel
requires an informed action to install on 10.10 and higher, through the selection of a variant. That should ensure there will be no binary packages (the variant is non-default), and I've tried to oblige the user to hunt a bit for the explanation on how to install the port. The variant could have a better chosen name, but I really think there is no good reason to require it on 10.9 .
comment:6 follow-up: 7 Changed 9 years ago by brendon.humphrey@…
Hi MacPorts,
Issue closed. Commentary removed.
The O3X project would prefer that if MacPorts are to carry a wrapped up installer, that the O3X project staff are treated as the first point of contact for releases or support going forward.
Thank you. Brendon
comment:7 Changed 9 years ago by RJVB (René Bertin)
Replying to brendon.humphrey@…:
It is distasteful for me to have to point out that O3X has a significantly negative relationship with @rjvb.
Distasteful? It's a bit more than that to come here and make claims about a supposed "relationship" there is between me and "O3X" suggesting I've engaged in who know's what kind of activity to hinder their efforts. That is simply not true, I wasn't aware of any bad feelings towards me nor have I ever or am I pretending to speak on their behalf. On the contrary, connecting to the IRC channel for the 1st time since months this morning I actually got what seemed like a warm welcome back without even having said a word.
I did have reasons in the past to avoid ZFS/OS X (a "case of didn't work for me"), thanks for replacing it with a new reason.
I cannot close this ticket but it now seems obvious it's best not to bother. My apologies for wasting server resources!
Changed 9 years ago by RJVB (René Bertin)
Changed 9 years ago by RJVB (René Bertin)
Attachment: | patch-dont-invoke-launchctl-145.diff added |
---|
Changed 9 years ago by RJVB (René Bertin)
Attachment: | patch-dont-invoke-launchctl.diff added |
---|
Changed 9 years ago by RJVB (René Bertin)
Attachment: | patch-kextloading.diff added |
---|
Changed 9 years ago by RJVB (René Bertin)
Attachment: | zfs_kexts_loaded.sh added |
---|
Changed 9 years ago by RJVB (René Bertin)
Attachment: | zfs_unload_kexts.sh added |
---|
comment:8 Changed 9 years ago by petrrr
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Motivated by some sort of tension with upstream, the reporter has preferred to revoke the submission and replaced the submitted files. So this submission becomes now pointless.
A version of the submitted files can presumably be found here
comment:9 Changed 9 years ago by RJVB (René Bertin)
Well, thanks, I had also removed that link from the comments, and requested to remove this ticket altogether.
Now, if there actually is interest in this port the whole issue can be rediscussed as far as I'm concerned, as long as someone volunteers to be a co-maintainer and also if it doesn't mean giving in blindly and completely to upstream conditions (after all they're free to submit their own proposition).
comment:10 Changed 8 years ago by raimue (Rainer Müller)
There is no way to completely erase all traces of a ticket. The whole discussion will still be available in the archive of macports-tickets@ which is also mirrored (for example on Gmane and Nabble).
comment:11 Changed 8 years ago by RJVB (René Bertin)
I wasn't expecting that. That is however no reason not to remove the original ticket; without its continued existence the traces remaining in collective memory will eventually lose credibility.
So there is a
pre-deactivate
stage, but interrupting deactivation takes a bit of a cannon ...