Basically I mean integration with the kernel's code base and all of the testing that entails. After their initial development, file systems all end up migrating to the kernel's code base.

So, I'm not thinking in terms of technical API support, but more development/testing/integration support.

That is not a requirement. ZoL has the most sophisticated build system of any Linux kernel module in the world to enable it to live outside of the main tree. ZoL relies on autotools' API checks to do this. In addition, the project has an automated buildbot that helps us to detect regressions in pull requests before they are merged. It is similar in principle to how lustre filesystem development is done. Lustre is also (primarily) outside of the tree and lived entirely outside of the tree for years.

That being said, being inside the kernel source tree is not necessarily a good thing. As I wrote in the blog post, other filesystems on Linux generally do not provide the latest code to older kernels, but ZoL provides the latest code to all supported kernels and distributions. This ranges from Linux 2.6.26.y to the 3.16.y in 0.6.3 and will include 3.17.y in 0.6.4. Something as important as a filesystem should be updated to fix bugs, even if the kernel proper cannot be. The inability of all Linux systems to update to the latest kernel is an issue that Linus Torvalds mentioned at LinuxCon North America 2014 and ZoL is one of the few filesystems that can deal with it on systems where it is deployed.

You know... I hadn't given much thought to Lustre. And that is a very good comparison. Lustre is completely out of kernel (in terms of development), so it's not like you're the first to try this.

I guess it really depends on where you want ZoL to be deployed. Lustre is typically deployed on HPC clusters and is managed by people who understand it, how to set it up, and how to manage it. It's not a trivial system to get working, and requires a pretty large budget. It just isn't setup on your typical server. Lustre also has a few big names behind it to provide development resources and support (Whamclound, now Intel).

What is the target market for ZoL? Do you want it to work on servers? Clusters? Personal workstations? They are very different markets.

I'm using ZFS right now for a single storage server that doesn't need to support a large cluster, so ZFS/NFS works great. But I'm using FreeBSD. For my Linux servers, I wouldn't think of using a filesystem that wasn't natively supported by Red Hat. I just don't want the management headache. I'm okay running a single FreeBSD box for my storage needs, but I'm fearful of what happens when I'd need to scale things out to multiple servers.

I wish you luck, I really do. It seems like you're not going into this blind and you're making good decisions. But it will be an uphill battle and you'll always have that specter of Oracle looming over you. It doesn't matter if you're technically/legally right on the licensing front - you'll still have it looming over you until Larry signs off on it (like you said below).

If you can get that sign off, then all bets are off, and you'd be golden!

The previous poster clearly does not understand that ZFS on Linux is essentially a native port with very careful dancing around licensing borders.

The previous poster is well aware of what ZFS on Linux is.

Licensing matters. It may not matter in terms of what I can do with my servers. I can compile ZFS and run it just fine on Linux. But you won't find Red Hat doing it. You won't find IBM doing it. Linus won't be adding it into the mainline tree anytime soon.

This means that there may be "technical" solutions to getting ZFS running on Linux, but that also means that there will be artificial barriers in place that will make it more difficult to run, test, deploy, and support.

These things matter.

I might use ZFS for Linux on a personal workstation, but there is no way that I'd add it to a production cluster.

I am working on tearing down barriers to this. Expect to see the fruit of that effort later this year.

That said, I do not consider absence from Linus' tree to be a barrier because being in Linus' tree limits the ability of end users to obtain bug fixes. That is a problem other filesystems have that I am happy to see ZFSOnLinux avoid.

Also, Linus Torvalds and I discussed the possibility of merging ZFS into his tree because of feedback like yours. In short, Linus has no interest in merging ZFS into his tree. Linus thinks that it might enable Oracle might sue people unless they provide a signed-off to confirm that the code is under the CDDL. He also thinks that the kernel signed off keeps Oracle from suing people over btrfs when software patents are a likely loophole.

Lastly, I realize that my statement about the signed off confirming that the code is under the CDDL might sound strange. However, there are two cases to consider. The first case involves source code. The GPL does not restrict the redistribution of source code, so there would be no problem. The second case is binaries, which the GPL does restrict in situations in which a court of law would consider to be a derived work. Being a module only option should be sufficient to deal with that. Linus did not seem to have any problem with that idea. However, he insists on Oracle's signed off with the preference that it be Larry Elison.

Right, but had you read the discussion this thread is about, you can see that Debian is working on a roadmap that includes binary drivers, shipped with the OS, available during the install.

Linus has traditionally done a poor job of ensuring that filesystems will work well in production, ext4 being a _fantastic_ example of that. I appreciate the work he does, but I don't quite give a fuck if he is scanning the source for my filesystem. I've seen more ext4 filesystems go corrupt than all others combined.

Red Hat and IBM can, equally, kiss my ass, I've never found either to be reliable.

I don't see how DKMS is really an artificial barrier to run, test, deploy, and support something. It is, in fact, the opposite of a barrier - it's a tool.

Debian is working on a roadmap that includes shipping source drivers to be slipstreamed in as dynamic modules.

DKMS is a tool, but it's hardly the same as a good, in tree module. I remember having tons of issues with DKMS WiFi drivers back when I still ran a Linux laptop (10-ish years ago). If you get an upstream kernel upgrade and the ZFS DKMS module doesn't compile against it, you're screwed. Can you imagine trying to debug DKMS issues with your main filesystem? I hope you leave an ext2/3/4 volume around for booting and root.

I'm glad that you feel like you can discount the work that IBM and Red Hat have done to advance Linux, but they've done a ton to make sure that Linux could take over data centers.

Good to know... Thanks!