ZFS FreeBSD moving to ZFS-on-Linux

U

usdmatt

https://lists.freebsd.org/pipermail/freebsd-fs/2018-December/027085.html

Looks like FreeBSD is going to be re-basing ZFS on the Linux port. The original port was based on OpenSolaris/Illumos which then moved to DelphixOS. However, Delphix have now announced they are moving to the Linux port.

It seems that there are numerous bugs that have been fixed in ZoL but never ported, so hopefully this should improve the code on FreeBSD, and also make it easier for OpenZFS changes to be merged into all the supported operating systems. Encryption for example was developed on ZoL.

Is does show the extent of the dominance of Linux though. ZFS is not yet a full part of Linux, but even so the developer base for ZoL is so much stronger than any other OS that it has now become the source of ZFS for everyone else. In some ways it seems a shame though that ZFS was originally a standout feature, touted for its solid integration with base, and we'll now be using ported code from Linux. I wonder how long it will be before some features are tied in with Linux subsystems, that either mean reduced functionality or performance on FreeBSD, huge porting effort, or the porting of additional Linux features.
 
Yep, I have already heard from one colleague who is dropping FreeBSD going forward based on this news; just run CentOS + ZoL. I will say the ZoL CentOS upgrades have always been hit-or-miss, and often require manually wiping out DKMS cruft and rebuilding the ZFS bits.

Hopefully ZoL will finally get TRIM support before this happens.

The best news out of this is that upstream (ZoL) sounds amenable to having the FreeBSD compatibility changes added directly to ZoL to have a (as much as possible) shared code base going forward -- three cheers for that!
 
Yeah, I was disappointed to see that 12 lacks native ZFS encryption, but this should bring that and a whole lot more. Trim support would be nice to have, but it's not necessary.

Also it will be nice to be able to pull a pool from a Linux box and mount it on FreeBSD and vice-versa.
 
This has been some time coming. The number of commits to ZFS from Linux developers has been massive. Hopefully this means that new eatures will be integrated more rapidly across the consortium.
 
I could see a future where for pure reasons of efficiency and cost savings one might want to just use ZOL on Linux. Would there by any advantage to using it on FreeBSD once both ZFS implementations are at parity?
 
This isn't going to end well for FreeBSD. Linux does not play well with others. It's only a matter of time before we see Linux system call creep/assumptions, broken pools between BSD/Illumos, re-invented "Linux only" features and so on.

The FreeBSD developers better be loud if they want to maintain ZFS relevancy. The FreeBSD team being "invited" to work on "their" codebase is meaningless BS.

We'll see though..
 
`Orum said:
Yeah, I was disappointed to see that 12 lacks native ZFS encryption, but this should bring that and a whole lot more.
Click to expand...

The implementation already exist done by iXSystems but it does need more testing before hitting the tree, and they are willing to solve some secure issues that do exist when it is used with dedup before merging it. The ZFS native encryption + dedup insecurity do exist in all implementations including the Oracle/Sun one.
 
The original idea of OpenZFS was to keep a general reference source for all involved parts. In practice that became just a mirror of the Illumos implementation which also seems to be always behind of the Linux and FreeBSD implementations.

So, what seems to be going to happen now is the use ZoL as that reference implementation since ZoL advance a lot of faster than the others; however at the same time it is lacking behind on several implementations already done on FreeBSD. So, the things needs to be adjusted somehow.

In practice, the thing is already pretty fragmented since none of those implementations are really portable.
 
Eric A. Borisch said:
Yep, I have already heard from one colleague who is dropping FreeBSD going forward based on this news; just run CentOS + ZoL.
Click to expand...
Now tell your friend to hold on here. I'll admit I was taken aback by all this and asking questions. I still don't have my head wrapped around this but I found these discussions on HN interesting and makes me think "dropping FreeBSD based on this" may be a mistake.

If the ZFS FreeBSD code are going to be taken from ZoL, what's the difference of use ZFS on FreeBSD and GNU/Linux?

FreeBSD can bundle it in the installer, and put the root filesystem in a ZFS dataset.
Because of GPL incompatibility with the CDDL, Linux cannot do this. A compliant installer must put root on something else, usually ext4 or xfs. A Linux installer iso putting root in a zfs dataset opens a terrible legal door.
Click to expand...
 
I know I'm only one person, but I use FreeBSD for a number of reasons, and ZFS has never been one of those reasons. I know that there are others who feel the same way about it. Hopefully all of the people who came to FreeBSD just because they wanted ZFS will have had time by now to catch on to all the other reasons for using FreeBSD.
 
Sorry, but this entire thread sounds like FUD. *Nothing* really changes other than the fact that illumos as "upstream" has become much less relevant in spite of Delphix moving away from it (AFAIU), and finally now there's a plan to finally make a reality what OpenZFS was intended to be -- a common repository having OS-independent code along with with OS-dependent parts being ZoL, ZoF, and so on.
 
Well, hammer2 maybe has : history, journalling, and a less-memory-intensive deduplication, could that be phased in in case Zfs goes south on BSD?
 
I'm not sure that HAMMER/HAMMER2 integration is that simple. Requires some drastic changes to the kernel as I recall.

(edit: though I remember reading that HAMMER2 addresses some of this?)
 
I don't think HAMMER will come to FreeBSD, and I see no reason that ZFS will go anywhere. It's just a bit of a shock that we're suddenly going to be taking ZFS code targeted specifically at Linux, then trying to undo any Linuxisms to merge into FreeBSD. Apart from being available in base, OpenZFS on FreeBSD will now always be lagging in features and fixes compared to ZoL. I do of course hope that the developers working on ZoL will make a conscious effort to keep any ongoing work as portable as possible, so that the various operating systems can keep up to date with minimum issues.

It's been a day and already there's talk that the current FreeBSD version has the only mature TRIM support, which now needs to be re-implemented in a way that will fit in with the ZoL code.
 
First, rebasing ZFS on ZoL does not mean stopping ZFS specific development on FreeBSD.
As I understand, ZoF is not a native FreeBSD project (It use OpenZFS), so ZoF will use ZoL as base instead of OpenZFS. Is not hat simple ?

Second, it is an opportunity to ask ZoL to be aware about portability and linuxisme. If the ZoL "team" (I don't know how this project is driven) accept the portability challenge, this is a very good thing for FreeBSD, but either OpenBSD, Mac OS X ...

Third, if ZoL is a robust and portable solution, FreeBSD developers can work in other projects.

I discover FreeBSD because I hear Mac OS X use a lot of FreeBSD core and the port manager was, for me, better than the yum installer. After that I discover the update and the documentation ... FreeBSD is not only ZFS and base the ZFS support on FreeBSD from ZoL instead of OpenZFS will not change the status of ZFS in FreeBSD...
 
drhowarddrfine said:
Now tell your friend to hold on here. I'll admit I was taken aback by all this and asking questions. I still don't have my head wrapped around this but I found these discussions on HN interesting and makes me think "dropping FreeBSD based on this" may be a mistake.
Click to expand...

I can understand both sides, but I am concerned about how long it will take for ZoF (The acronym I've seen for ZFS On Linux (on FreeBSD)) to be shaken out. Look at all the still-ongoing discussion about ZFS memory management and race conditions on FreeBSD after how many years. Now rip out one version of ZFS, put in another that has been focused on Linux memory management best practices, and wait for the dust to settle...

I really hope it goes well. I certainly understand the motivation, given the momentum that ZoL has been developing, and the additional features they seem to keep adding, to "rebase" off of ZoL. The fact that it sounds like a version of it is up and running is somewhat reassuring, and the indication that Behlendorf (ZoL maintainer) is willing to have the FreeBSD switches (#ifdefs, etc) in the mainline is also a promising sign. FreeBSD also likes to boot off ZFS, and BEs (another major selling point) rely on it. Now the bootcode needs to be touched again (non-trivial; check out the 12.0 upgrade messages on this board) to handle the new ZoF versions, and likely more frequently as they keep adding features.

All the other goodness of FreeBSD still exists. I can still actually read the code and find and change things when I want to. The unified base system rather than Kernel / Distro(user) split. The ability for mortals to build the entire system with the tweaks they would like. The ports tree.

But "we've got the most stable ZFS" (impression or truthiness I leave to you) will likely no longer be the case. And for some, that was all that mattered.
 
usdmatt said:
I do of course hope that the developers working on ZoL will make a conscious effort to keep any ongoing work as portable as possible, so that the various operating systems can keep up to date with minimum issues.
Click to expand...

I do not have high hopes of this happening. The velocity of change in Linux is too drastic, and they've had a track record of unwillingness to take in account the needs of other platforms, or to maintain interoperability of software.

There will be a culture clash - because we (FreeBSD) have different values and approach to software development. I suspect a scenario where the Linux commits will be more frequent (which have been - due to a larger developer base). These commits will assume Linux interfaces or have fundamental changes to the inner-pinnings of ZFS, which will hamper FreeBSDs ability to merge improvements with the least of amount of friction. Or code quality will suffer. Linux's response will be "Sorry bro!, this is how we work - take it or leave it", and it all goes down from there.

Maybe I'm just being pessimistic about the situation - but i do not trust Linux to be fair and handle a project of such magnitude and prestige. Their culture just doesn't permeate reasonable values.
 
drhowarddrfine said:
It would be good to read Allan Jude's comment on this from the mailing list.
Click to expand...

I've read the thread. Also from the same thread;

The ZFS test suite is in ZoL under tests, it makes some Linux specific assumptions about paths to binaries like ksh etc and it appears to require some additional configuration options.
Click to expand...

They can be invited all they want, but if these assumptions get more specific - improvements will never make it back to FreeBSD. Of course, this is all conjecture but I'm still on edge about this; Linux's history isn't to be ignored.
 
Beastie7 said:
I've read the thread. Also from the same thread;



They can be invited all they want, but if these assumptions get more specific - improvements will never make it back to FreeBSD. Of course, this is all conjecture but I'm still on edge about this; Linux's history isn't to be ignored.
Click to expand...

Let me repeat myself, this is in no way different from current situation, zfs-tests suite currently makes A LOT of solaris-like assumptions; it uses ksh as it's the system shell in ex-opensolaris.

All this thread is about can be summed up in "bad, bad, bad linux, I don't like them".
 
yuripv said:
Let me repeat myself, this is in no way different from current situation, zfs-tests suite currently makes A LOT of solaris-like assumptions; it uses ksh as it's the system shell in ex-opensolaris.
Click to expand...

Again, the difference between illumos and Linux is that there are shared values of software development and the illumos team has maintained an effort of interoperability. So the adaptation process wasn't much of a hassle.

All this thread is about can be summed up in "bad, bad, bad linux, I don't like them".
Click to expand...

And I say "Embrace, Extend, Extinguish"
 
There's no "illumos team", such thing never existed, and no one ever cared about interoperability with any downstream. All ZFS development was done by Sun, and then continued by Delphix. If you did really read the link posted above, it explicitly says that those same developers will continue to work on ZFS, just in the different repository, trying to be OS-agnostic.
 
You must log in or register to reply here.
Back
Top