ZFS On Linux Runs Into A Snag With Linux 5.0

[GrayShade]

Next why is ZoL using floatpoint without fallback for platforms without floating point. Yes x86 cpus without floating point are still made.

It's not using floating point, it's using SIMD to accelerate the checksum computation. And it does have a fallback. Should ZFS run slower on Linux because it's not GPL?

[ferry]

OpenZFS is a fork and it's *not* a corporate filesystem project. They have ZERO involvement with Oracle. It's license is similar to MPL (are you reading this in Firefox, it's MPL too) and one could argue it's more permissive and free than Linux itself. (hence it's inclusion in FreeBSD, Mac OSX, even Microsoft Windows now. The only place it's "not allowed" is Linux.)

So no corporate backing, then? Maybe that's the problem then. Now read my comment again.

[PuckPoltergeist]

And this highlights the difference between Windows and Linux. On Windows, APIs get depreciated, but they still functionally work. And Linux, they just remove the API then blame everyone else when their previously working software stops working.

And this highlights why I stopped developing for Linux over a decade ago.

If you're unable to adopt your software to API changes within 5 years, you should stop developing software at all.

[some_canuck]

If you're unable to adopt your software to API changes within 5 years, you should stop developing software at all.

I don't think its unreasonable to ask for an API to not change without warning people, and I don't mean a hidden email on a mailing list that gets a million messages a day. Yes, they were trying to get rid of this since 4.2, so put warnings the configure/compile phase in so people know they're getting rid of it. If you use make -s, well that's on you.

[Awesomeness]

Thread tl;dr.

ZFS on Linux uses SPL (Solaris Porting Layer). SPL is under GPL, therefore not a legal problem.

The precedence of Andrew FS, which Linus himself commented on, see https://lkml.org/lkml/2003/12/3/228, makes it clear that ZFS's CDDL if fine from the Linux kernel's point of view because it has not been written for Linux. It was written for another OS (Solaris in ZFS's case) and "just happens" to work with Linux because of SPL.

[PuckPoltergeist]

I don't think its unreasonable to ask for an API to not change without warning people, and I don't mean a hidden email on a mailing list that gets a million messages a day. Yes, they were trying to get rid of this since 4.2, so put warnings the configure/compile phase in so people know they're getting rid of it. If you use make -s, well that's on you.

Unfortunately that's not the way the Linux kernel development works. If you develop your driver outside the upstream kernel, you're on your own. Bring it upstream, and you will be notified about such changes or even better, the one who change the API will fix your consumer.

Btw, is ZFS on Linux limited to x86? The only other arch where the symbols were exported is s390. When my code is such special, I should follow the appropriate ML. And the change was announced on linux-x86.

[Space Heater]

So no corporate backing, then? Maybe that's the problem then. Now read my comment again.

ZoL has corporate backing, I don't know why you think it doesn't. Nobody is trying to upstream ZFS to Linux.

Some organizations that use and contribute to ZoL include: datto, Delphix, OS Nexus, and Lawrence Livermore National Labs.

On Windows, APIs get depreciated, but they still functionally work. And Linux, they just remove the API then blame everyone else when their previously working software stops working.

And this highlights why I stopped developing for Linux over a decade ago.

Sounds like you are confusing userspace and kernel space APIs, even Windows doesn't guarantee kernel API stability forever.

[johnc]

My tolerance for ZFS is pretty non-existant. Sun explicitly...

Wow, dude. That was 20 years ago. What kind of infantile gamma holds a grudge for that long?

[NotMine999]

Wow, dude. That was 20 years ago. What kind of infantile gamma holds a grudge for that long?

I agree.

I would also submit to Greg K-H that if FP code in the Linux kernel code is "unstable" and "should not be used and that's why we deprecated it", then Greg K-H should do the noble thing by falling on his sword and organizing a project within the Linux kernel team to fix the d@mn Linux kernel code for these FP calls that is "unstable".

I think Linux kernel code fixing is squarely within the wheelhouse of Greg K-H and the Linux kernel devs, but it's easier for them to say, "Nobody using it anymore, and besides it's unsafe code, so it needs to be deprecated." while never saying, "We don't know crap about how to fix that unstable code."

And a few notes for Greg K-H personally:
Your NIH attitude belongs at Mozilla, not within Linux kernel development where the spirit has been to not lock up control of a user's own computer away from it's owner/user.

Blocking access previously given to the FP function (or specifically the SIMD instructions, as someone mentioned in this forum) that are embedded within the CPU that is in the computer that the user likely owns is JUST PLAIN WRONG. If there is no Linux API to access them, then Linux is BROKEN BY DESIGN and should be tossed in the bit bucket. Otherwise, STUFF YOUR ATTITUDE and suggest the proper API(s) to access these CPU features via Linux; try being helpful instead of hurtful.

Frankly Greg K-H, your elitist NIH attitude and the entire stupid GPL concept in the Linux kernel code shows how far some in the Linux kernel development community have strayed from the founding concepts of Linux itself. Linux is becoming a "walled garden" or at least "a very exclusive garden" due to people like you and Linux companies like Redhat and Oracle.

[Ananace]

And this highlights the difference between Windows and Linux. On Windows, APIs get depreciated, but they still functionally work. And Linux, they just remove the API then blame everyone else when their previously working software stops working.

And this highlights why I stopped developing for Linux over a decade ago.

This is actually a really interesting subject, on one hand you have Linux where the Kernel holds itself to a golden standard where it is never allowed to break user space by its internal changes, and on the other hand you have the full Windows operating system where they will actively modify, add, and remove kernel space code while at the same time writing fallback code to avoid breaking your deployed applications due to these changes.
As a fun experiment, the command `fsutil 8dot3name query c:` in your Windows commandline will - for instance - show you if you have MS-DOS compatible path name generation enabled for your hard drives, a feature that makes sure that every file on your system is addressable by applications that can only understand 8+3-char path segments, something that was the case for applications written for DOS and early 16-bit compatible Windows versions. Disabling this feature on a modern system can give you a file access speedup when dealing with deep folder structures.

I personally stopped developing for Windows because of how amazingly annoying it is to develop for with their insane mess of a system API collection they have, redefining common names all over the place, providing functions that can have different effects depending on unrelated other functions you may or may not have called earlier, other functions that can have wildly different contracts that apply based solely on the name of your application, interfaces that haven't been relevant since the non-networked era but without any notice about this, etc.
And the worst part is that the documentation is really bad about these things, so if you ever stumble onto one of these instances then you can end up deep in a real debugging hell, one where you'll most likely only ever find your way out by mistake - if you don't simply give up and implement your own workarounds for the issues you run into.

Developing for Linux - especially when doing lower level user space programming - on the other hand is really nice, everything is fully documented with every possible outcome based on your input, and while you can still access basically all of the older APIs still, you often get good examples for more modern methods that are better suited for solving your problems.