Release new versions with kernel major release, making porting to new kernels higher priority

[gentoosys]

Hi. I like ZFS and use it more than 10 years. But my kernel upgrade depends from zfs release, and sometimes need to wait about a month or more.
Will be great to make porting to new kernels higher priority and release a new version right after kernel release. All checks may be done on release candidates.
Thanks for your work.

[n0xena]

you can override the kernel version check: #16574 (reply in thread)

[amotin]

@gentoosys This is a community project, so you are welcome to test things yourself in advance, report any found issues and when possible propose patches. Thanks to several people caring about it, we are usually not too far back, but it is a constant process that would benefit from more participants.

[jaen]

While I understand you shouldn't rush filesystem releases and throughput is limited by how much time people can volunteer, I would also say it's not always clear what the kernel compatibility status is, what is blocking the version bump and when the next release will be.

And while the former is hard to fix without more qualified people working on ZFS, I think that visibility could be improved a lot by e.g. having a "Project" or a tracking issue (or maybe even an early release PR) per each kernel version and/or release where issues and PRs relevant to the milestone are gathered and you can see at a glance whether there are still kinks that need to be worked out, or maybe the code is expected to work well enough for people to start testing it.

The last few kernel releases had PRs for compatibility fixes, which did already help, but it wasn't 100% clear from them at which point you could have a reasonable expectation of the changes being complete enough for end-users to try it on their (less critical) machines.

Anyway, I personally don't mind the status quo too much because on NixOS I can easily pin or patch things when I need to (and in fact I sometimes try releases earlier), but I think that even if there are not enough people to make releases themselves faster, improving clarity on release status and timeline could be only beneficial.

[tonyhutter]

We've been trying to improve the process to get releases out quicker.

One big change is: #17156

It allows us to install a custom kernel version + run the test suite. I used it today to verify we can run against the the 6.14 kernel. This allowed us to bump our supported version number to 6.14 (#17172) on the same day as the 6.14 kernel was released.

We hope to have a new ZFS release out for it soon.

[tonyhutter]

Proposed patchset for 2.3.2: #17214

[gentoosys]

Ok well, thank you all for feedback.
You said, that 6.14 is supported.
I am using Arch and zfs-dkms from aur. If I install 6.14 kernel, the latest version 2.3.1 will fail to build module, because 2.3.1 have a check <=6.13
Will be cool, if you release 2.3.1.1 version, which is the same as 2.3.1, but supports 6.14 kernel.
And do like that after every new kernel release.
Thanks

[snajpa]

It's actually very simple, either more people help with this or nothing changes. As it stands, a kernel version being marked as compatible means nothing, that is, if you expect it to be stable with that version, it isn't. It takes a bit more time to uncover bugs coming from hasty code bending, which is done just to get it to compile on those newer versions. Nobody in the project currently has time to do much more than such hasty code bending, that's just the reality of a volunteer-driven project, especially as large as this one. The burnout of existing experts is real.

It's currently not stable even with 6.12 LTS, so there's that.

Of course anyone can open an issue, but just by opening such a request, nothing is going to change.

If you use OpenZFS in prod, consider contracting one of the companies contributing to OpenZFS to get support with current kernel releases, the budgets need to increase, the number of hands capable of moving the needle needs to go up - either by volunteer enthusiasm or paid customer support.

[n0xena]

please see n0xena/archzfs#17
I provide a patched dkms with this flag included so it should work fine with 6.14 https://github.com/n0xena/archzfs/releases/tag/2.3.1-6.13.8