The long term problem with ZFS on Linux is its license

January 25, 2015

Since I've recently praised ZFS on Linux as your only real choice today for an advanced filesystem, I need to bring up the long term downside because, awkwardly, I do believe that btrfs is probably going to be the best pragmatic option in the long term and is going to see wider adoption once it works reliably.

The core of the problem is ZFS's license, which I've written about before. What I didn't write about back then because I didn't know enough at the time was the full effects on ZoL of not being included in distributions. The big effect is it will probably never be easy or supported to make your root filesystem a ZFS pool. Unless distributions restructure their installers (and they have no reason to do so), a ZFS root filesystem needs first class support in the installer and it will almost certainly be rather difficult (both politically and otherwise) to add this. This means no installer-created filesystem can be a ZFS one, and the root filesystem has to be created in the installer.

(Okay, you can shuffle around your root filesystem after the basic install is done. But that's a big pain.)

In turn this means that ZFS on Linux is probably always going to be a thing for experts. To use it you need to leave disk space untouched in the installer (or add disk space later), then at least fetch the ZoL packages from an additional repository and have them auto-install on your kernel. And of course you have to live with a certain amount of lack of integration in all of the bits (especially if you go out of your way to use a ZFS root filesystem).

(And as I've seen there are issues with mixing ZFS and non-ZFS filesystems. I suspect that these issues will turn out to be relatively difficult to fix, if they can be at all. Certainly things seem much more likely to work well if all of your filesystems are ZFS filesystems.)

PS: Note that in general having non-GPLv2, non-bundled kernel modules is not an obstacle to widespread adoption if people want what you have to offer. A large number of people have installed binary modules for their graphics cards, for one glaring example. But I don't think that fetching these modules has been integrated into installers despite how popular they are.

(Also, I may be wrong here. If ZFS becomes sufficiently popular, distributions might at least make it easy for people to make third party augmented installers that have support for ZFS. Note that ZFS support in an installer isn't as simple as the choice of another filesystem; ZFS pools are set up quite differently from normal filesystems and good ZFS root pool support has to override things like setup for software RAID mirroring.)

Comments on this page:

Well, I have a couple disagreements with your post.

First, while Linux installers don't natively support ZFS now, that doesn't mean that setting up a root ZFS filesystem cannot be performed in the installer. It can. You can get a shell, add ZoL to your repository's configuration, and install ZFS just like you would on a regular storage server. After which, you'll need ZFS support in GRUB, which Solaris pushed patches upstream for, and you'll need the kernel module bundled in your initramfs. Expert work indeed, but not impossible, and not terribly difficult.

Second, although ZFS will not be mainline due to license incompatibilities, ZFS is Free Software. As such, distributions can ship the kernel module as part of the installer. The installer itself would likely need to be modified to include some of the ZFS layout peculiarities, as well as the ZFS commands, but shipping a filesystem as a kernel module as part of the distribution's installer is no big deal.

You are spot on that users would need to demand it though. And with Btrfs being mainline, and some of the myths surrounding ZFS, I don't see that happening. As such, don't expect installing ZFS while you're still in the installer, to be simple. It won't be.

By Chris at 2015-01-25 11:46:53:

I agree with Bryan Cantrill in where he says that no one has standing. Who's going to bring a case against it? The ZFS developers? Doubtful; they're a pragmatic bunch who want their code to be used. Linus? He's just as pragmatic. The FSF is the only body that I can think of that would care, and even then I think it would be a waste of their time. What are they going to say? "You got your open source software mixed with our open source software"? It's not their software. It's Linus's and the other kernel developers'. There may be some overlap, I suppose, between the set of kernel hackers and FSF members who would care enough. But again, it seems so doubtful.

I've actually spent a few years working on tools to easily enable Gentoo Linux users to set up their systems on root on ZFS. I've tried to make it as easy as possible. I've been running zfs for about 2-3 years now and my system has been solid. There are of course a few things to always keep in mind (like you said, there is a lack of integration), but besides that, the technology itself stands on its own.

specifically: bliss-initramfs. bliss-boot and bliss-kernel are there to bring up a system up even faster, but the initramfs is the main component. It even supports different types of encryption at boot level (key, key_gpg, and passphrase).

I forgot to comment on the licensing this. IANAL, but this is a non issue. It isn't really a requirement to include the ZFS modules in the kernel, of course it isn't ideal, but with the benefits ZFS provides, it is completely manageable. Distributing kernel modules linked to the kernel isn't illegal (Linus spoke about how this is a gray area and that different modules would need to be looked at different, Example: if Another OS ported a filesystem to Linux when it wasn't designed for Linux in the first place, then in his mind, this wouldn't be considered a derivative work of the Linux kernel). Also if someone even does decide to sue based on these grounds, then NVIDIA and Oracle would have to step up to the plate since they also make and distribute kernel modules that are linked against the kernel but are kept proprietary. Ultimately, if the person suing wins, only the Linux community loses (Mainly from what I can recall at the moment, no more NVIDIA proprietary drivers, etc).

By Chris at 2015-01-26 11:39:51:

Exactly--the only victory to be had in a lawsuit about ZFS in Linux would be Pyrrhic, and I don't think even the FSF would go there.

Using the product.img feature of Anaconda it might be possible to package the installer support separately from anaconda itself.

By cks at 2015-01-26 14:55:39:

My view on the licensing issue is that it is not the actual possible or likely legal outcome that matters, it is a combination of the risks involved and the social aspects of a license clash. On the risks: the reaction of most distributions to legal uncertainty and risk is generally to err on the side of not getting sued, even if they might win a legal case in the end (and I think this is a sensible reaction). Right now there is clearly risk.

(Note that because the Linux kernel does not require copyright assignment, my understanding is that many people believe that any significant Linux kernel contributor has standing to sue if they want to. A number of such contributors are on record as feeling significantly different than Linus on these issues. Such a case might or might not be won, but again risks.)

On the social aspects: many distributions care not just about the letter of the law and what the outcome of a lawsuit might be but also what the spirit of things are. The CDDL was clearly created in part so that ZFS could not be mixed with the GPLv2 Linux kernel and it's clearly the wish of at least some of the Linux kernel people that the kernel be strongly GPLv2. Shipping ZFS with your Linux kernel in a combination that is not mixable under the spirit of the licenses involved is clearly against this social view of things, even if you can get away with it legally. As a result I think that at least some distributions (I would guess at least Debian and Fedora) would be strongly against it as an official thing even if it was sure that they would never get sued over it.

Written on 25 January 2015.
« Web applications and generating alerts due to HTTP requests
Some notes on keeping up with Go packages and commands »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jan 25 04:20:46 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.