OSNews

What political issues? The only problem of ZFS, as far as Linux is concerned, is that its license is GPL incompatible.

Licensing is political. NIH is also a political issue.

But the problem is that GPL is too restrictive. Thus ZFS couldn't be included in Linux kernel and Btrfs(also GPL) won't be easily included in other operating systems. If I understand correctly...

sun could make zfs gpl. there was talk about it as a trade for linux kernel drivers.

but they chose not to because they are launching new products that use it, and it is a big differentiating feature between them and linux.

That's life. Seriously. Choices have consequences, and some of them are beneficial and some of them are not. It is unlikely that ZFS will see inclusion in the Linux kernel, and it is unlikely that btrfs will see inclusion in the *Solaris kernel. (Should that be plural or not?) Sometimes those kinds of barriers are significant, and sometimes they are not. I am not convinced that the sharing of filesystem code has much benefit over cross-pollenation of *ideas* in this particular case, for reasons which I have outlined elsewhere in this thread.

I find that discussions on licensing often end up doing nothing more than generating bad blood and resentment between the various parties, without yielding any meaningful benefits.

An impedance mismatch between the ZFS architecture and Linux kernel architecture is *not* political, however. Sun's goals for ZFS, apparently, are for it the be the Solaris filesystem. And there is absolutely nothing wrong with that. That strategy has its strengths. And in that case, putting the layering of logical levels into ZFS itself makes perfect sense. However, supporting a broad range of filesystems is a strategy which also has its strengths, and that is what Linux does. In that case, having all the layering of raid, volume manager, fs, etc. in ZFS itself makes no sense at all.

No NIH is required to see that ZFS, while a good fit for Solaris, is a poor fit for Linux.

As to licensing... that does have a political aspect. But the problem is primarily a practical one from the Linux kernel devs standpoint. Although an argument could be made that Sun's choice of license might have been motivated by political (or perhaps "strategic" would be a better word) factors.

Edited 2008-04-30 16:44 UTC

I don't think that argument holds, since Btrfs is busy copying all the "layer violation" features from ZFS such as RAID.

No. That is a mischaracterization. Btrfs is intended to work closely *with* dm and lvm. A certain minimum amount of functionality is duplicated between btrfs and the current dm and lvm where absolutely necessary. Read what Chris says about this:

http://lwn.net/Articles/265533/

Edited 2008-04-30 17:59 UTC

So? What makes ZFS completely unsuitable for Linux is the fact that it's not just a filesystem - not even a "filesystem + volume manager". ZFS is a complete software stack from the VFS to the storage driver.

This is why ZFS supports io priorities and UFS-solaris doesn't: They have the "old" IO stack and the "new" ZFS stack. In the Linux kernel this would not be acceptable at all. When Linux develops a new piece of the IO stack such the io priorities, it must work for all the filesystems. If that piece only works with a filesystem, it'd be considered misdesigned and would not be merged. This is why in Linux you have IO priorities support not only for a given filesystem like ext3, but also for filesystems like FAT - for any kind of filesystems, in fact the io priority thing doesn't interacts so much with the filesystems, but with the block devices.

So if ZFS were GPL, some parts would be need to be redesigned to be merged in Linux. BTRFS, in the other hand, is just a filesystem that plugs cleanly in the Linux design.

In general I don't think you are incorrect. However, I don't think this is literally true. For instance, I am pretty sure that each major Linux FS implements journaling using its own private subsystem. There is a standard subsystem now, JBD, but only ext3 uses it.

Moral of the story is, if the right political factions are behind it, anything goes.

I would disagree with that. Duplication of journaling layer code is one thing. Especially considering that XFS, JFS, and Resierfs were introduced before jbd and ext3. It's an unfortunate situation, but what can we do now? Rewrite them all to use JBD? Reiserfs was introduced back when we Linux folks had a pretty bad case of "journal envy". XFS (and to a lesser extent, JFS) carried too much of a mystique to refuse. Those were different times. If reiserfs v3 were new today it would not get the easy ride that it did back then, Hans or no Hans.

Besides that, JBD holds a different status than, say, VFS, DM, MD and LVM. ZFS's wholesale duplication of pretty much the whole stack is in a completely different class of design dissonance than simply using one's own journaling layer.

I don't understand why people are so quick to claim politics when the technical reasons for concern are so clear. I think that it's maybe because these kinds of threads spend so much time in "conflict mode" where honest expression of concerns about impedance mismatches quickly devolves into "ZFS Rulez!, ZFS Sucks!" affairs.

My position is that ZFS is great for Solaris, and bears a lot of good ideas that many of us would like to see in a Linux filesystem. But I really don't think that porting ZFS is the answer, even disregarding the obvious licensing issues. The desirable features of ZFS really need to be added in the appropriate places in the Linux stack to really work well and have a chance of becoming default Linux filesystem features. ZFS is a round peg. *Solaris is a round hole. Linux is a square hole, and needs a square peg with all the nice features of the ZFS round peg included in the appropriate places. Btrfs is a pragmatic start on that. It is, in my opinion, just ambitious enough, but not *too* ambitious to be a practical starting point. (We should not expect always to be on the cutting edge of everything. A little patience, and appreciation of others' achievements is called for.)

This discussion would really be more interesting if the subject were ZFS's suitability for MacOSX or FreeBSD where the licensing allows the question to be relevant. And, of course, the designers of those kernels are entitled to their own ideas about what is appropriate in their kernels. After all, they are the ones who must support these filesystems on into the future.

Edited 2008-04-30 20:45 UTC

You're right...it being GPL, it has its own political issues.

ZFS and the Linux kernel are incompatible. End of story.

Edited 2008-04-30 20:48 UTC

Would it be illegal to ship a compiled Linux kernel along side some ZFS source code that has been modified to work with the kernel, and then supply a script to compile it as a module?

I definitely see how shipping a kernel binary with that support built directly into it would be illegal. But if you leave it to the end user to build it is it illegal?

That would still be illegal. If you really, really need ZFS that bad then I'd suggest to go to http://zfs-on-fuse.blogspot.com/