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

[duby229]

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. NVIDIA has the same problems on Fedora as OpenZFS. Both modules highlight Fedora's limitations as a consumer oriented OS more than anything.



In tree and out of tree is a bullshit thing that some people bring up as a way to "prove" that something will or won't have some form of maintenance burden. They don't realize how much lives out of tree waiting to be deemed good enough to be included in the kernel or that once it is included that someone has to step up and constantly update it else it'll risk being kicked out of the kernel like ReiserFS and old architectures. Frankly, in or out of tree, all it does is highlight that the kernel needs better long term stability in regards to an ABI or API.

"But it's out of tree" ain't the flex or argument they think it is.



I've been having this same argument since 2016. Nothing has changed. If a person needs more than just a file system then only real solutions on Linux are the cluster+fuck+file/system options and OpenZFS. Everything else on Linux pales in comparison to OpenZFS. Even if BTRFS were to get more features, it probably won't ever have the fine grained per volume/dataset controls that OpenZFS has so BTRFS will never by an option for someone who already uses OpenZFS or who uses the cluster+fuck and wants a simpler solution. While I'm hopeful for Bcachefs, it's still a decade or so out from being anywhere near the level of OpenZFS as well as it might need some of the cluster+fuck.

In tree or out of tree, that is an argument that definitely matters... Let's face the facts here and admit that Linux is never going to get a stable ABI. It's not going to happen.... In tree there are something like 2000 regularly active devs and they have an obligation to keep the kernel compiling.... Out of tree there is you and your friends and you guys have no obligation to anyone but yourself...

EDIT: And that is the position that ZOL takes, they only port to LTS releases and it is highly unlikely you can get it to compile on any other kernel releases. It's not their obligation and they don't care.

EDIT: The entire concept of LTS releases are stupid as f___k. I would so much rather see Major.Minor version control.

EDIT: Right now Major versions are totally arbitrary and minor versions don't mean anything except to act as a release snapshot where bigger numbers are newer than smaller numbers. Honestly with the way that Linux releases kernels they'd be way better off with a date based version system than the nonsense they use now.

[skeevy420]

In tree or out of tree, that is an argument that definitely matters... Let's face the facts here and admit that Linux is never going to get a stable ABI. It's not going to happen.... In tree there are something like 2000 regularly active devs and they have an obligation to keep the kernel compiling.... Out of tree there is you and your friends and you guys have no obligation to anyone but yourself...

And those some-odd 2000 regularly active devs are almost all paid for their work. That's just like how a lot of the OpenZFS devs are paid for their work. If you follow the trail they're funded by the US Department of Energy. OpenZFS is critical for American infrastructure to operate so it won't be going away anytime soon.

EDIT: And that is the position that ZOL takes, they only port to LTS releases and it is highly unlikely you can get it to compile on any other kernel releases. It's not their obligation and they don't care.

OpenZFS already has 6.10 and 6.11 work done and they don't only port to LTS releases. Do you really believe that? I've used OpenZFS since 2016 so I can assure you that LTS only statement is wrong. Fuck, this article even highlights that OpenZFS works on up to Linux 6.9 which is not an LTS kernel.

Oh, and there is no ZoL anymore. It's all under the OpenZFS umbrella. It has been for a while.

[royce]

EDIT: The entire concept of LTS releases are stupid as f___k. I would so much rather see Major.Minor version control.

EDIT: Right now Major versions are totally arbitrary and minor versions don't mean anything except to act as a release snapshot where bigger numbers are newer than smaller numbers. Honestly with the way that Linux releases kernels they'd be way better off with a date based version system than the nonsense they use now.

Feel free to fire up an email to lkml to propose this to Torvalds. I'll grab the popcorn.

[mbod]

In tree or out of tree, that is an argument that definitely matters... Let's face the facts here and admit that Linux is never going to get a stable ABI. It's not going to happen.... In tree there are something like 2000 regularly active devs and they have an obligation to keep the kernel compiling.... Out of tree there is you and your friends and you guys have no obligation to anyone but yourself...

You will always have out of tree. This will not go away. And out of tree has advantages because you can keep a driver version constant while the kernel version changes. That is a big plus for stability and prevents regressions. Many zfs installation are still running on versions 1.2.x, 2.1.x or even 0.8.x.

EDIT: And that is the position that ZOL takes, they only port to LTS releases and it is highly unlikely you can get it to compile on any other kernel releases. It's not their obligation and they don't care.

That is simply not true. You seem to miss some education regarding zfs.

EDIT: The entire concept of LTS releases are stupid as f___k. I would so much rather see Major.Minor version control.

LTS releases are mandatory for servers. It sounds like you are a private user enjoying your laptop, always going to the latest and greates kernel. That is fine in that scenario. But if you are running a data center with several hundred servers you need to have LTS.

EDIT: Right now Major versions are totally arbitrary and minor versions don't mean anything except to act as a release snapshot where bigger numbers are newer than smaller numbers. Honestly with the way that Linux releases kernels they'd be way better off with a date based version system than the nonsense they use now.

I dont care about major.minor numbers. I agree that the numbering is more or less arbitrary. But I do care about LTS versions. I want to keep the kernel stable and only receive bug fixes and security fixes. That is mandatory.

[royce]

I absolutely love ZFS, but being out of tree is a major pain in the arse. I'm moderately optimistic about bcachefs catching up to at least the featureset I need.

[pWe00Iri3e7Z9lHOX2Qx]

EDIT: And that is the position that ZOL takes, they only port to LTS releases and it is highly unlikely you can get it to compile on any other kernel releases. It's not their obligation and they don't care.

They are constantly working on compatibility with new stable kernels. The initial commits for this typically happen extremely early in the kernel RC development cycle. For example...

• 6.10 isn't officially supported yet, but the PR for the compat changes was submitted on June 6th which is only 4 days after 6.10 RC2 was released: https://github.com/openzfs/zfs/pull/16250
• 6.11 compat PR: https://github.com/openzfs/zfs/pull/16400

But like I said, if you value your data, you are best off waiting for official support. The early compat PRs can't catch everything. E.g. this for 6.9 https://github.com/openzfs/zfs/issues/16089.

I use ZFS with Tumbleweed and use zypper locks to stay on officially supported kernels. But soon I'll just transition their new LTS kernel builds and not worry about it.

[NotMine999]

I will stay with ZFS on Linux (even with it's licensing hassles & Oracle background) and the need to recompile code when a new ZFS driver on Debian is release with a kernel update ...

... rather than trust my data to some "hand waving, don't look behind the curtain, yeah that feature is still in the development pipeline, sorry you lost data in that crash we'll fix it in a future update, so what if we changed the filesystem layout forcing you to spent hours (or even days?) rebuilding your datastore"filesystem that's about as stable as a drug dealer who is constantly sampling their merch.

[fitzie]

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.

this is cope. openzfs used to come out at around x.y.5-6 release, but this time they didn't put out a release until 6.9 is already EOL. they've tried to do something which no filesystem has done in a long time, which is to be compatible with six years of kernels in one branch. that is not how any other filesystem is doing development and some this is partly because they are licensing issues, but some of this is just of project decisions. we don't actually know why they decide to release when they want to and clearly the commercial interests don't really care about it, but from an enthusist standpoint, they should commit to something like we'll put a a release within four weeks of a new kernel.

Asked another way, why do they not care about users who use the latest kernel?

[intelfx]

Even if BTRFS were to get more features, it probably won't ever have the fine grained per volume/dataset controls that OpenZFS has so BTRFS will never by an option

My personal Btrfs tree that I'm developing for myself has those and much more already

[skeevy420]

this is cope. openzfs used to come out at around x.y.5-6 release, but this time they didn't put out a release until 6.9 is already EOL. they've tried to do something which no filesystem has done in a long time, which is to be compatible with six years of kernels in one branch. that is not how any other filesystem is doing development and some this is partly because they are licensing issues, but some of this is just of project decisions. we don't actually know why they decide to release when they want to and clearly the commercial interests don't really care about it, but from an enthusist standpoint, they should commit to something like we'll put a a release within four weeks of a new kernel.

Asked another way, why do they not care about users who use the latest kernel?

The SCX governor switcher was rejected because the governors themselves live out of tree and might need to be fixed between kernel versions. That's really not that different than OpenZFS or the non-free NVIDIA driver needing fixes after the kernel updates.

Asked another another way, why do the kernel maintainers not care about all the out of tree incompatibilities caused by their design decisions?

This is a circular argument where all sides end up being simultaneously right and wrong. "Quit breaking things in the name of progress" is no better than "keep up with the Joneses" when you get down to it. Linux LTS is just a middle-ground solution for those two sides of the argument. I don't know what the best solution is, only that the status quo isn't necessarily the best.