Announcement

Collapse
No announcement yet.

OpenZFS 2.2.5 Released With Linux 6.9 Support, Some Linux 6.10 Bits

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

  • #21
    Originally posted by skeevy420 View Post

    Yep. That kernel argument is rather moot since most distributions don't ship the latest stable kernel and most rolling release distributions have LTS kernel options. It's only when you run a development and testing OS like Fedora that's used by a lot of GNOME, GNU, and GPL diehards that you have a problem.
    Out of tree modules are a burden for plenty of people. It's not just one specific distro that includes the latest kernel updates. It's arch, gentoo and all rolling releases and everybody else who needs the latest kernel for better hardware support. No, having a LTS kernel option doesn't solve for this since latest hardware support is not backported and LTS kernels also lag behind heavily even for security updates. None of the consumer oriented distros use LTS kernels by default for the same reason. Over time, third party kernel modules have steadily declined in popularity and I don't see that changing. Even Nvidia I suspect will have a performant mainlined driver not too far in the future.

    Comment


    • #22
      Originally posted by spicfoo View Post

      Out of tree modules are a burden for plenty of people. It's not just one specific distro that includes the latest kernel updates. It's arch, gentoo and all rolling releases and everybody else who needs the latest kernel for better hardware support. No, having a LTS kernel option doesn't solve for this since latest hardware support is not backported and LTS kernels also lag behind heavily even for security updates. None of the consumer oriented distros use LTS kernels by default for the same reason. Over time, third party kernel modules have steadily declined in popularity and I don't see that changing. Even Nvidia I suspect will have a performant mainlined driver not too far in the future.
      If you agree that out of tree modules are a burden, but at the same time there are legitimate reasons why things are developed out of tree, thats what a stable ABI is designed to solve.

      No matter how hard Linux kernel dev's will try, you are never going to have ZFS be an in tree driver anyways due to licensing issues.

      Comment


      • #23
        Originally posted by mdedetrich View Post

        If you agree that out of tree modules are a burden, but at the same time there are legitimate reasons why things are developed out of tree, thats what a stable ABI is designed to solve.
        Regardless of the legitimacy of them, they are a burden and Linux kernel developers explicitly disagree with your notions of a kernel modules ABI. So harping on that doesn't help with the burden at all.

        Originally posted by mdedetrich View Post
        No matter how hard Linux kernel dev's will try, you are never going to have ZFS be an in tree driver anyways due to licensing issues.
        It's up to Oracle to fix the licensing issues. They did it for DTrace eventually.



        They can do that tomorrow if they want to for ZFS. It doesn't have to be GPL either. Plenty of code in the Linux kernel is under a GPL compatible permissive license.

        Comment


        • #24
          Originally posted by mdedetrich View Post

          If you agree that out of tree modules are a burden, but at the same time there are legitimate reasons why things are developed out of tree, thats what a stable ABI is designed to solve.

          No matter how hard Linux kernel dev's will try, you are never going to have ZFS be an in tree driver anyways due to licensing issues.
          But a stable internal ABI isn't going to happen. I do think most people at least partially would agree with your logic. But it isn't gonna happen.

          Comment


          • #25
            Originally posted by spicfoo View Post

            Out of tree modules are a burden for plenty of people. It's not just one specific distro that includes the latest kernel updates. It's arch, gentoo and all rolling releases and everybody else who needs the latest kernel for better hardware support. No, having a LTS kernel option doesn't solve for this since latest hardware support is not backported and LTS kernels also lag behind heavily even for security updates. None of the consumer oriented distros use LTS kernels by default for the same reason. Over time, third party kernel modules have steadily declined in popularity and I don't see that changing. Even Nvidia I suspect will have a performant mainlined driver not too far in the future.
            Everything is a burden for plenty of people. In tree, out of tree, it's all maintenance burden for someone and they're almost all paid for the work they do.

            The consumer oriented distributions do use their in-home kernels, some of which are supported for upwards of 10 years distribution depending. They do that because Linux's actual LTS options aren't good enough. Way back in the day distributions would offer RHEL kernels, too, as a way of having a universal Linux option. Arch, Gentoo, and all those rolling releases have LTS kernels available, but they might not be good enough when compared to some RHEL or Ubuntu kernels with 10 years of patches and support for new hardware.

            The way it all works creates that burden. Existing LTS isn't good enough for commercial distributions and Stable releases offer no guarantee of backwards compatibility or an expectation that the system will always work in the same way. Technically speaking, Linux stable is unstable due to its very nature and being.

            LTS is only good enough if you're a home user using OpenZFS or NVIDIA or you need a backup in case Linux Stable breaks something. It's not actually long term enough to matter for anyone else. And by LTS I mean the latest LTS release, 6.6. But you should search the AUR for the term "DKMS". There are over 400 packages. Most of them are out of tree modules. Out of tree isn't declining at all. They're just not as necessary with consumer hardware these days so we don't really use them as much, but they're still there for esoteric hardware, proprietary graphics, and commercial uses like Crowdstrike.

            What sucks is that eBPF could have potentially solved this problem but it was done in a way that is CDDL incompatible.

            Comment


            • #26
              Originally posted by skeevy420 View Post

              Everything is a burden for plenty of people. In tree, out of tree, it's all maintenance burden for someone and they're almost all paid for the work they do.
              That's rather hand-wavy. The point is that out of tree presents an unique burden above and beyond anything in the tree because of the Linux kernel development model. If you want the latest hardware support, the best performance and all of the security fixes, you can't use LTS and if you don't use LTS, out of tree modules frequently are out of sync. That's the fundamental issue. Works fine for RHEL style distro users but that's for regular desktop users.

              Comment


              • #27
                Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post
                At the end of the day, if you want to run OpenZFS on Linux, you are way better off using LTS kernels.
                Nah, it has been flawless for ages using the rolling release distro VoidLinux. For me it is even slightly better than ZFS on FreeBSD, despite the setback of it being a module (due to Oracle's lying about being so FOSS friendly).

                Comment


                • #28
                  Originally posted by deusexmachina View Post

                  Nah, it has been flawless for ages using the rolling release distro VoidLinux. For me it is even slightly better than ZFS on FreeBSD, despite the setback of it being a module (due to Oracle's lying about being so FOSS friendly).
                  This statement doesn't make any sense. Void doesn't magically make new kernels that aren't supported by ZFS officially supported or even possible to build the modules against. It works in Void because you are specifically using old enough kernels, just like any other rolling distro. Right now that means using the packages for 6.1->6.9. When zfs won't build against Void's linux-mainline package, you are SOL without one of those older kernels. It's the same as using LTS kernels in Arch / Tumbleweed, or locking packages to some older (and now EOL) kernel.

                  Comment


                  • #29
                    Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post
                    Void doesn't magically make new kernels that aren't supported by ZFS officially
                    But I didn't claim that. The kernels available in Void are plenty recent. Usually around the 4th point release of the latest kernel is when Void has a working zfs module. Which is nice because by then the kernel is better tested as well. Again, has worked flawlessly for many years straight and the only one within sight to blame in this situation is Oracle.

                    Comment


                    • #30
                      Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post
                      At the end of the day, if you want to run OpenZFS on Linux, you are way better off using LTS kernels. Even if your distro cherry picks the early compat changes, there's no guarantee that those are complete and compat bugs can be found later (happened in 6.8). So you either hold / lock the latest officially supported kernel, go the LTS kernel route, or cherry pick and cross your fingers.
                      Point to the diagram of the Linux kernel where ZFS hurt you. 🤣

                      Been using ZFS with ArchLinux and linux-zen for over a year now using the AUR zfs-dkms-git and zfs-utils-git packages. Day 1 kernel compatibility.

                      Linux-lts... Hold on while I laugh!🤣 Hah hah!
                      ​​
                      Last edited by ReaperX7; 18 August 2024, 10:14 AM.

                      Comment

                      Working...
                      X