Linus Torvalds Doesn't Recommend Using ZFS On Linux

[sb56637]

Linus is unfortunately dead wrong in his assessment of ZFS being technically irrelevant and unmaintained, but he’s also unfortunately spot on with his warning about the legal dangers.

As a Linux user, I *want* ZFS. I’m sure that BtrFS works fine for tons of users, but lamentably it has also burned tons of users. Brand reputation is incredibly important for a file system, and it only gets one chance to establish mindshare. In that sense, BtrFS blew it, whether or not it has improved or can be improved technically.

[betam4x]

Of course, Linus Torvalds has little control over the behavior of out-of-tree modules and it's always been his position to not maintain a stable driver API/ABI and they won't bend over backwards for closed-source/out-of-tree code.

...which is one of the Linux Kernel's biggest failings. At what point do we stop adding drivers to the source code? Having a fixed driver API wases development, improves security, and helps with compatibility.

[Tsuroerusu]

And as far as I can tell, it has no real maintenance behind it either any more

My first thought when I read that was "Man, Linus sure is out of the loop in regard to ZFS!". It sounds like he is entirely unaware of the OpenZFS project which has several companies behind it. Also with the recent move by FreeBSD to adopt ZFS On Linux as their upstream the development and maintenance efforts are even stronger.

Now, to steelman what Linus is saying for a moment, OpenZFS also makes re-licensing it as GPL even more complicated because even if Oracle were to re-license the version from which they forked, every contributor since then would have to sign on to the re-licensing for it to be able to go ahead. Most of the Oracle code in OpenZFS has been replaced so that would be a monumental task.

Finally, because of Oracle's nature, even if they wanted to re-license ZFS as GPL they would most likely release their own closed source version as GPL, or even port it to Linux themselves and then release it. That would do little to help OpenZFS as it would still be a derivative work of the final version from OpenSolaris which was under CDDL. Oracle would have to retroactively re-license all past ZFS work for OpenZFS and its participants to then be able to begin a process of contacting every single contributor they have had for the past, almost, 10 years since the fork.

So yeah, this situation is probably not going to change. What I do find a bit sad is that the Linux kernel developers still seem so bitter about Sun's decisions that they let their understandable enmity towards Sun colour their view of the OpenZFS project and its developers. I am like "Guys, they are NOT your enemies!". I am not saying that the kernel developers should spend their time paying attention to out-of-tree projects, let alone support them, but there is a decent way to not do that and there is a negative way of approaching the issue caused by a decade-long loathing of Sun.

[starshipeleven]

...which is one of the Linux Kernel's biggest failings. At what point do we stop adding drivers to the source code? Having a fixed driver API wases development, improves security, and helps with compatibility.

Kernel developers have different opinions, and made a FAQ in the kernel source to address this kind of common bs arguments https://github.com/torvalds/linux/bl...i-nonsense.rst

[starshipeleven]

As a Linux user, I *want* ZFS. I’m sure that BtrFS works fine for tons of users, but lamentably it has also burned tons of users.

The same can be said of any filesystem

[nomadewolf]

I've never seen the point of ZFS when we have Btrfs...

BTRFS is a bit of a mess.
Maybe if they can sort it out...

[andyprough]

The same can be said of any filesystem

Especially when the file systems are used inappropriately by people who have little or no idea what they are doing.

Every time we get one of these articles, I see comments by users promoting uses of the file systems for things that the maintainers specifically warn us against doing because they are unsupported. But, folks have lots of cheap, old hard drives laying around, and feel that they must utilize them in certain configurations regardless of the risk of data loss.

[danmcgrew]

Especially when the file systems are used inappropriately by people who have little or no idea what they are doing.

Every time we get one of these articles, I see comments by users promoting uses of the file systems for things that the maintainers specifically warn us against doing because they are unsupported. But, folks have lots of cheap, old hard drives laying around, and feel that they must utilize them in certain configurations regardless of the risk of data loss.

And ESPECIALLY when a computer is "used" by people who have no other real work to do.

[ChamPro]

Try activating SMART. We can detect bit-rot on the hardware level.

Wohhhhh there. SMART does not detect bitrot. SMART is sensor monitoring to anticipate hardware failures. This can be related to bitrot, but will not detect it in files or fix it for you like checksumming+redundancy in a filesystem.

Personally, I've found btrfs to be lacking (RAID5/6 usage, ease of use, analytics) and have stayed with ZFS in the move from BSD to Linux at home. It helps that I'm familiar with ZFS in the enterprise.

[carewolf]

Wohhhhh there. SMART does not detect bitrot. SMART is sensor monitoring to anticipate hardware failures. This can be related to bitrot, but will not detect it in files or fix it for you like checksumming+redundancy in a filesystem.

On traditionally spinning disks it will, because the read mechanism uses statistical error-correction and detection, so it can tell if the signal is muddy and ambigious and warn you. Chances of a flipped bit or two passing the error-correction are astronomically small. It mostly fails when entire sections are damaged physically.