Announcement

Collapse
No announcement yet.

ZFS On Linux Runs Into A Snag With Linux 5.0

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • GrayShade
    replied
    Originally posted by oiaohm View Post
    On hardware with proper checksum hardware accelerators ZFS on Linux not being GPL is going to be slow vs GPL file-systems in the Linux kernel doing checksums.

    This is one of the problems you hit when you go to freebsd from linux is that hardware accelerators no longer have drivers and it not possible to write a non GPL driver for them.

    There big issues with ZFS on Linux or anyone else thinking they will do checksum at high performance while not using GPL. So yes ZFS is running slower because its the wrong license + avoid code of right license.
    Using SIMD to compute the checksums is fast enough and is not covered by patents with exceptions for GPL code. This isn't about hardware accelerators. It's about arbitrarily denying non-GPL modules access to SIMD. Do you believe it makes Linux better for anyone?

    Leave a comment:


  • oiaohm
    replied
    Originally posted by GrayShade View Post
    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?
    SIMD has to have the same protection switches as using FPU. Thank you intel for deciding to recycle some the less stable register copy operations in side their cpus..

    The Linux kernel has a crypto_shash that wraps over all you hardware acceleration for checksums. Really bad news to use a lot of the hardware accelerations you need patent licenses Guess what OIN has got those patents license for the Linux kernel. Wait for the other shoe to drop. The patent license that OIN aquired only cover you if your code is GPL.

    On hardware with proper checksum hardware accelerators ZFS on Linux not being GPL is going to be slow vs GPL file-systems in the Linux kernel doing checksums.

    This is one of the problems you hit when you go to freebsd from linux is that hardware accelerators no longer have drivers and it not possible to write a non GPL driver for them.

    There big issues with ZFS on Linux or anyone else thinking they will do checksum at high performance while not using GPL. So yes ZFS is running slower because its the wrong license + avoid code of right license.

    Video card drivers are normally MIT or equal license so they code when built against Linux can use GPL only features. Remember there are many GPL only features that are GPL only because of patents and they are patented because they provide high performance.

    CDDL being a conflicting license is badly restricting ZFS on Linux hands.
    Last edited by oiaohm; 01-12-2019, 12:54 AM. Reason: Extra note

    Leave a comment:


  • Marc Driftmeyer
    replied
    1. Existent
    2. Sun is no longer an entity and last I checked Oracle contributes to Linux.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by gamerk2 View Post
    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.
    This is not true for windows kernel ABI. This is why Drivers from windows XP without service pack don't work on XP with service pack. Or modern day drivers that works on first version of Windows 10 don't work on current versions of Windows 10.

    Inside kernel space does not matter where you are ABI/API breakage will come.
    Last edited by oiaohm; 01-12-2019, 02:36 AM.

    Leave a comment:


  • Almindor
    replied
    Originally posted by NotMine999 View Post

    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 [email protected] 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.
    Why don't you follow your own advice and find a workaround for them or submit patches to the kernel to enable a better way instead of telling someone who is either developing on free time or being paid to do proper in-tree work to change their attitude.

    The arrogance is on your side here, Greg has all the rights to say what he did, you have 0.

    Leave a comment:


  • Ananace
    replied
    Originally posted by gamerk2 View Post

    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.

    Leave a comment:


  • NotMine999
    replied
    Originally posted by johnc View Post

    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 [email protected] 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.

    Leave a comment:


  • johnc
    replied
    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?

    Leave a comment:


  • Space Heater
    replied
    Originally posted by ferry View Post
    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.

    Originally posted by gamerk2 View Post
    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.
    Last edited by Space Heater; 01-11-2019, 05:27 PM.

    Leave a comment:


  • PuckPoltergeist
    replied
    Originally posted by some_canuck View Post

    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.

    Leave a comment:

Working...
X