Hacker News Reader

Comment by detaro | Hacker News Reader

I'm curious in what way ZoL is "shoehorned to fit the OS"? Sure, a port adds potential for error, but is the technical difference between the interfaces so large?

View on HN

The ZoL code is not the shoehorning, it's the fact that you're doing so via a community effort to go around the official stance of the kernel developers who've explicitly opted to not support this FS at this time; meaning you're missing out on all the normal development and QA processes and the benefits thereof. There's real value in having the the actual OS community designing the filesystem as well, their experience cannot be discounted.

This isn't just applicable to Linux; we have a strict policy on using only in-kernel filesystems on FreeBSD as well after some poor experiences (_in production_) with aufs-esque ports to FreeBSD. They all look shiny and nice on the outside, and even stress test OK, but when you release them to the masses that's when the shit hits the fan and you realize they're just not designed to the same specifications as the rest of the OS components.

The kernel developers would probably accept zfs if they could. The main blocker is a license incompatibility issue, which is worked around by distributing zfs in source code form.

It's not about whether they could if they would. It's that they didn't, and therefore the things they'd have done if they would have didn't come to pass.

I'm saying it didn't matter why. Just that at the end of the day, the kernel team isn't opting their weight behind this, and that should factor in to the decision.

The Linux Kernel project doesn't own the Linux Kernel developers; those that wish to contribute to ZFS on Linux will do so and those that do not wish to will not. Things aren't quite so black and white in the open source world. Just because something isn't in Linus's tree doesn't mean it doesn't get testing and communication doesn't happen. In fact, because it's designed as a module and we have the DKMS infrastructure, being out of mainline really isn't as big an issue as it might have been in the past for distribution. There are disadvantages surely, but keeping up, taking advantage of interested talent and being in the know aren't really huge examples of them -- especially for an established project like ZFS on Linux.

EDIT: I would also like to explicitly point out the false equivocation to which I am responding. The idea that the Linux Kernel project ignoring the code because it has an incompatible license is, in any way, equivalent to the Linux Kernel Project maintainers choosing to not "throw their weight" behind a piece of code by mainlining it -- essentially that they are rejecting it due to lack of technical merit -- is specious at best and deliberately instils fear, uncertainty and doubt at worst.

Do you know what development and QA processes are in place for in kernel filesystems and how that compares to ZoL's development and QA process?

There are no QA processes per se for all file systems. The kernel is pretty much a bundling of many projects and the big file systems are their own projects, managed largely indepently from the Linux masters.

They are probably referring to the fact that in the Linux world, in-tree modules get a lot of maintenance for free when the kernel refactors the pieces beneath.

If you have ever written a kernel module out of tree then tried to upgrade the kernel version you know this pain.

Reply on news.ycombinator.com