Linux 6.11 compatibility and new promptly release

[wiesl]

As support for Linux 6.11 has not formally been added in zfs 2.2.6: Is it possible to release a new zfs version in a promptly manner (e.g. 2.2.7)?

Thnx.

[n0xena]

I remeber a similar question a while ago - the reply basically was: The next release gets pushed when it's ready.
Or to put it this way: Don't demand formal support for 6.11 if it's not done proper. There're still several issues with 6.11 everyone is working on hard - and only when the team is convinced it did a good enough job they will release 2.2.7 with proper 6.11 support. Or, as 2.3.0-RC1 was released: Could be there will be no 2.2.7 with 6.11 support but rather 2.3.0.

[n0xena]

looking at #16630 guess we won't see a 2.2.7 but rather 2.3.0 for 6.11

[darkbasic]

You can use this if you use Arch Linux: https://aur.archlinux.org/packages/zfs-dkms-staging-git

[n0xena]

DKMS is not required - look at: https://github.com/archzfs/archzfs/releases

[darkbasic]

@n0xena where does experimental pull from? No branch exists with support for the latest version of the kernel on top of a stable zfs release, you have to backport patches from the development branch.

[n0xena]

@darkbasic enjoy yourselfs a good read: archzfs/archzfs#545
also: if anyone feels risky I also provide pre-builts: https://github.com/n0xena/archzfs/releases
from where we pull from: from here - just with some shell code to generate arch-specific PKGBUILD for pacman - the 2.3.0 I use on my builds is just a re-pack as for some reason arch doesn't seem to like stuff like "-rcX" and I'm not smart enough the make it work otherwise
also: the builds target the arch official supported kernels: standard (linux), zen, hardened and lts - dkms is also provided but as arch doesn't official support any other kernels as those provided by the repos anything require dkms is unsupported from arch anyway

[darkbasic]

Hi @n0xena and thanks for your work. That thread is very long and I'm not super motivated into reading it since I maintain zfs-dkms-staging-git on the AUR anyway, but I'm still interested if you're willing to sum it up.

Do you release into the official archzfs repo or do you still work in your own fork?

Do you backport compatibility patches on top of the stable zfs branch or do you provide it "as is" with the upstream limited kernel compatibility?

If you're into backporting maybe we can keep ourselves in touch since I'm doing the same for the dkms and might be valuable to share our findings.

[n0xena]

to summarize:

there's also a topic on the arch bbs: https://bbs.archlinux.org/viewtopic.php?id=298463

I'm by no means a dev or maintainer - all I do is to provide pre-built packages as I was one of the first ones to do so and currently keep doing it
I use github merely for the reason so others don't have to trust me but can check for themself what I did (or rather: that I did not changed anything) and re-do what I did by themselfs - what I did: updated to current zfs, added the fix for broken kmod 33-1 (which shouldn't matter anymore since its revert with kmod 33-2), and for the sake of convenience I matched the build user name to what I use on my systems

the gist of the linked issue are two topics:

a) proper signing of the packages - currently there's the idea to create a master key which is signed by several maintainers - basically copying the arch-keyring - I also proposed the idea of having this archzfs-keyring signed by the arch-keyring so any arch user can just use it

b) what to support how: do we call LTS the stable branch? or do we provide a recent kernel supported by the lates non-rc release of zfs? what about providing rc builds?
why do I keep provide packages although there're already some more recent official-ish proper build, tested and signed packages: basically just for redundancy until the archzfs figures itself out - which likely will happen after 2.3.0

as for dkms: the way I understand dkms is that it's rather a framework to provide smooth automated kernel-module build for custome kernels as modules can only be loaded by the kernel they're build against - so any pre-built package provide has to be build for a specific official provided kernel - which arch only supports the main one, lts, zen and hardened - so the archzfs project will target to only provide pre-builds for them - with dkms for anything user-built
hence I personal don't really care about dkms or keep pointing it out - as anyone actualy requiring it should know about it anyway - anyone else who uses distribution provided standard kernels should use packages/modules built for them instead of fooling around with dkms on a standard kernel a pre-built exists
the archzfs repo is setup to do a auto build once a day against the then current kernel - so even if a hotfix or bad timed release results in a off-by-one it should be auto-fixed within 24h - a timeframe even arch users should be able to wait

[darkbasic]

which arch only supports the main one, lts, zen and hardened - so the archzfs project will target to only provide pre-builds for them - with dkms for anything user-built

Pre-built modules or dkms doesn't really matter: the problem is that if you target Arch's main kernel most of the times you can't use either a stable zfs release nor the staging branch since they don't backport compatibility patches in a timely manner. Even now 2.2.x still doesn't provide a satisfying experience with Linux 6.11.

That's why I backport patches from the development branch against latest stable zfs release. What do you do in that regard? Do you keep using latest stable zfs release hoping that it works like what archzfs used to do or do you backport compatibility patches? If it's the latter I think there is margin for collaboration between us.

[n0xena]

@darkbasic if you not already got in contact with some of the more appropriate "leaders" over on the archzfs project I'd like to redirect you to the linked issue and drop a comment there to get added to the active dev/maintainer group
from what I got so far is that your point is in active discussion about what and how to provide support
the team is aware that currently the only way to get support from both arch and zfs is to use latest zfs release with current lts kernel - everything else has to be considered at least unstable or even experiemental
there's also the idea about providing matching kernel versions along with what zfs supports - if this includes active backports or any support from the broader arch-community? I don't know - all I can refer to is to the rules of the arch bbs which state "support for current versions of mainline kernels only" with an explicit hint that before posting any help requests to make sure that the system is up-to-date and to check for yourself if an issue persist when switching to lts
those who took over the active maintaining of the archzfs project are far more into all that stuff that I am and it's possible that I relay informations wrong - my point for replying here was just to point out that demanding support for most recent linux kernel just doesn't work and that support for 6.11 will be released when it's ready
as for arch and zfs we drifted quite off-topic from OPs original "question"

[edgan]

#16621 is a minor issue with zfs-2.2.6 and 6.11 kernel.

[Golbinex]

I would appreciate if 2.2.7 still got released because my new SBC is supported only in 6.11+ kernels and ZFS 2.3 brings some new major features which could take some time before it reaches stable.

[ssergiienko]

It happen https://github.com/openzfs/zfs/releases/tag/zfs-2.2.7 🎉

[behlendorf]

Closing. zfs-2.2.7 was released which includes support for 6.11 and 6.12 kernels.