Biggest Linux Kernel Release Ever Welcomes bcachefs File System, Jettisons Itanium (theregister.com) 52
Linux kernel 6.7 has been released, including support for the new next-gen copy-on-write (COW) bcachefs file system. The Register reports: Linus Torvalds announced the release on Sunday, noting that it is "one of the largest kernel releases we've ever had." Among the bigger and more visible changes are a whole new file system, along with fresh functionality for several existing ones; improved graphics support for several vendors' hardware; and the removal of an entire CPU architecture. [...] The single biggest feature of 6.7 is the new bcachefs file system, which we examined in March 2022. As this is the first release of Linux to include the new file system, it definitely would be premature to trust any important data to it yet, but this is a welcome change. The executive summary is that bcachefs is a next-generation file system that, like Btrfs and ZFS, provides COW functionality. COW enables the almost instant creation of "snapshots" of all or part of a drive or volume, which enables the OS to make disk operations transactional: In other words, to provide an "undo" function for complex sets of disk write operations.
Having a COW file system on Linux isn't new. The existing next-gen file system in the kernel, Btrfs, also supports COW snapshots. The version in 6.7 sees several refinements. It inherits a feature implemented for Steam OS: Two Btrfs file systems with the same ID can be mounted simultaneously, for failover scenarios. It also has improved quota support and a new raid_stripe_tree that improves handling of arrays of dissimilar drives. Btrfs remains somewhat controversial. Red Hat banished it from RHEL years ago (although Oracle Linux still offers it) but SUSE's distros depend heavily upon it. It will be interesting to see how quickly SUSE's Snapper tool gains support for bcachefs: This new COW contender may reveal unquestioned assumptions built into the code. Since Snapper is also used in several non-SUSE distros, including Spiral Linux, Garuda, and siduction, they're tied to Btrfs as well.
The other widely used FOSS next-gen file system, OpenZFS, also supports COW, but licensing conflicts prevent ZFS being fully integrated into the Linux kernel. So although multiple distros (such as NixOS, Proxmox, TrueNAS Scale, Ubuntu, and Void Linux) support ZFS, it must remain separate and distinct. This results in limitations, such as the ZFS Advanced Read Cache being separate from Linux's page cache. Bcachefs is all-GPL and doesn't suffer from such limitations. It aims to supply the important features of ZFS, such as integrated volume management, while being as fast as ext4 or XFS, and also surpass Btrfs in both performance and, crucially, reliability. A full list of changes in this release can be viewed via KernelNewbies.
Having a COW file system on Linux isn't new. The existing next-gen file system in the kernel, Btrfs, also supports COW snapshots. The version in 6.7 sees several refinements. It inherits a feature implemented for Steam OS: Two Btrfs file systems with the same ID can be mounted simultaneously, for failover scenarios. It also has improved quota support and a new raid_stripe_tree that improves handling of arrays of dissimilar drives. Btrfs remains somewhat controversial. Red Hat banished it from RHEL years ago (although Oracle Linux still offers it) but SUSE's distros depend heavily upon it. It will be interesting to see how quickly SUSE's Snapper tool gains support for bcachefs: This new COW contender may reveal unquestioned assumptions built into the code. Since Snapper is also used in several non-SUSE distros, including Spiral Linux, Garuda, and siduction, they're tied to Btrfs as well.
The other widely used FOSS next-gen file system, OpenZFS, also supports COW, but licensing conflicts prevent ZFS being fully integrated into the Linux kernel. So although multiple distros (such as NixOS, Proxmox, TrueNAS Scale, Ubuntu, and Void Linux) support ZFS, it must remain separate and distinct. This results in limitations, such as the ZFS Advanced Read Cache being separate from Linux's page cache. Bcachefs is all-GPL and doesn't suffer from such limitations. It aims to supply the important features of ZFS, such as integrated volume management, while being as fast as ext4 or XFS, and also surpass Btrfs in both performance and, crucially, reliability. A full list of changes in this release can be viewed via KernelNewbies.
Jettisons Itanium? (Score:4, Interesting)
Itanium is still being used and sold today, it's supported by HP at least until 2025. I know there are still quite a few of those up and running, mostly OpenVMS, but after HPE sold OpenVMS some people are opting to switch to Linux. After support ends, you'll see people running it commercially for at least another decade.
Linux supports some very esoteric old stuff, including PowerPC and MIPS, which must have even less users. Not sure what the problem is with keeping a stable product in the source tree.
Re:Jettisons Itanium? (Score:5, Informative)
Summarizing lwn https://lwn.net/Articles/95046... [lwn.net] According to the maintainer of the EFI subsystem: it is nearly impossible to test boot sequence on Itanium because of no availability of physical machines or availability is only remote (which is a problem for failed boot sequences), and he wrote "while I know of at least 2 people (on cc) that test stuff on itanium, and package software for it, I don't think there are any actual users remaining". The maintainer of glibc was also in favour of dropping support for Itanium. A group of hobbyists was interested in maintaining but kernel+glibc would be quite a lot of work.
Re:Jettisons Itanium? (Score:5, Informative)
Re: (Score:1)
China is using MIPS for MANY internal projects, so you can say MIPS is VERY important
Re: (Score:2)
It is MIPS or RISC-V. MIPS, from what I know is superseded by RISC-V. I have seen a lot of advances on the RISC-V front from China.
Re: (Score:3)
> some people are opting to switch to Linux
Do you know if any of them spoke up? Itanium has been on the chopping block for quite a while - this is just the final step.
Re:Jettisons Itanium? (Score:5, Informative)
Article author here.
Yes, people complained, and I wrote about it:
https://www.theregister.com/20... [theregister.com]
Torvalds made a counter-offer, a very reasonable one. AFAICS it did not happen.
Re: (Score:1)
I never even heard of it until now, which is a problem. I know a few companies that rely on Itanium stuff and again, it's still being sold today with 5 and 10 year contracts.
Re:Jettisons Itanium? (Score:5, Informative)
I followed this on the mailing list through links when this was announced a while back, and there are basically no users.
No one on the kernel teams have an actual physical itanium box, meaning they cannot test booting/etc. Leaving it in means having an unstable and untested component in the mainline kernel which is an obvious no-no.
So if you know some people with hardware who are willing to pay a few developers to maintain the code and give them hardware I'm sure there would be a case to put it back in. Linus has even directly said that if a team kept an out of tree patchset going for a year or two he would seriously consider a merge and readding it.
If there are a lot of business doing critical work on Itanium that's a very small ask of them.
If it's a few hobbiests then ......
Re: Jettisons Itanium? (Score:2)
Re: (Score:3)
Re:Jettisons Itanium? (Score:4, Informative)
Article author here.
> Itanium chips will be fab'd until 2025
I believe that this is completely untrue. As far as the Reg knows, manufacture ended in 2020.
https://www.theregister.com/20... [theregister.com]
Re:Jettisons Itanium? (Score:4, Informative)
Some of those people will probably be willing to pay for careful security backports; some will just firewall it and roll the dice; but neither are really of any interest to the mainline kernel.
Worse, there's no incentive whatsoever to use it outside of that handful of legacy cases: it was produced in fairly modest quantities; and the last significant improvement in the architecture was with Poulson chips in late 2012(Kittson came in mid 2017 but was on the same process side and included no architectural improvements; the project was on life support at that point); and even at release Itanium was having a pretty good day when it traded blows with Xeons; so we're talking something between a Sandy Bridge Xeon on a bad day and maybe a Haswell one with a following wind; except really obscure. Also no afterlife as an embedded instruction set or other niche application; it was only ever one product line.
Re: (Score:3)
Article author here.
> PowerPC and MIPS, which must have even less users.
Not at all.
PowerPC is a cost-cut single-chip variant of POWER, which is still in active development and on sale.
PowerPC was the basis of the Gamecube, Wii, Wii U, Sony PS3, and Xbox 360. They sold in the hundreds of millions of units. And a decade of PowerMacs, of course.
Itanium sold in the thousands, maybe tens of thousands. Not hundreds. It was a vast scale flop.
Because there are so many millions of PowerPC units, not only is it t
Re: (Score:1)
In it's heyday, Dell, HP etc. shipped about 50-60k units per year. Again, I know of at least one company that still ships units today with a 10y support contract (OpenVMS and Linux). The problem is that customers like that rarely listen in on obscure mailing lists where these things get announced and the tech media rarely picks it up until now when the support is effectively removed, especially since Linux has a very stable kernel API, it is excellent for long term support. Although it seems since Kernel 6
Frustrating (Score:5, Interesting)
Watching the journey of, first, btrfs, and now bcachefs, has been extremely frustrating in light of the mere existence of ZFS. bcachefs looks like it's a far cry more sane in its implementation specifics than btrfs (and certainly more stable/less likely to corrupt your storage), but their mere existence is due to "not invented here".
The kernel team has intentionally stonewalled functionality and gone so far as to implement silly things poorly (see: their attempt at doing "extended ACLs" for ext4), avoiding the more obvious and useful functionality (filesystem-level NFSv4 ACLs) so as to spite ZFS users. They've done other things, but that's the most obvious and significant overt hostility, and it's hurt cross compatibility in general: NFSv4 ACLs are a superset to Windows ACLs, so instead of the mangled "extended ACLs" implemented (exclusively) for ext4 which break traditional u/g/a permissioning with a 'strap on' functionality that only half works, we could have the real thing across all linux filesystems (including zfs). This would be really helpful for not only the in-kernel cifsd but samba compatibility/interoperability.
Re:Frustrating (Score:5, Informative)
That may also come back to the licensing issues, especially if it came from Oracle ZFS.
Re:Frustrating (Score:5, Informative)
Watching the journey of, first, btrfs, and now bcachefs, has been extremely frustrating
File systems are not a priority for the tech companies that fund Linux developers. There are relatively few people actually dealing with Linux file system work today, whereas there were significantly more in the past, despite the fact that most of the legacy file systems were comparatively simple. The most widely used file systems in Linux (ext4, xfs, etc.) are all basically in maintenance mode today.
Few people care about the kernel's various obsolescent file systems because they rely on SAN devices that provide file and block service, cloud systems that provide file and block service, proprietary hardware to manage aggregated devices, clustered software defined storage (Ceph, et al.) and other solutions that all do effectively the same thing from the perspective of the Linux OS: segregate the responsibility for managing storage away the OS. When some sort of abstract block device is used by a Linux kernel the file system used to scribble a name space on it doesn't really matter much.
What does that mean for bcachefs? Sadly it's probably never going to get the amount of developer horsepower needed to really iron out the work well enough that someone could put into mission critical service. It's very ambitious and a great achievement that it's gotten as far as it has, but don't kid yourself: bcachefs is going to need years of work by dedicated talent, and there isn't anyone willing to write the checks to fund all that.
Re: (Score:2)
Oh, that's fucking hilarious. Bravo, sir.
Re: (Score:1)
Oracle won't promise to not hurt the linux community with a lawsuit or relicense Sun ZFS yet the linux community helps Oracle.
Larry might call them 'retarded communists' for this state of affairs, but how would I know? Thar's silly talk.
Re:Frustrating (Score:5, Insightful)
Oracle is the one creating the uncertainty of a potential hostile environment. Quit blaming the kernel team for yet another hostile corporation.
Re: (Score:2)
Sun Microsystems, actually - designing a license of Solaris, some say deliberately incompatible with GPL.
https://en.wikipedia.org/wiki/... [wikipedia.org]
c.f. btrfs whose creator was working at Oracle.
Re: (Score:3)
Thanks for letting me know you don't understand the problem being commented on.
Explain to me why you think it's Oracle's fault that the Linux kernel team implemented an inferior, incompatible "extended ACL" which kludges up things, instead of implementing compatible and broadly supported NFSv4 ACLs (fully supported on AIX, FreeBSD, MacOS, JFS2)? Apple implemented NFS4 (and NTFS) ACLs a full THREE YEARS before MacOS X came out.
Meanwhile, those ACLs would be useful for being able to natively manipulate ACLs o
Re: (Score:2)
Your gonna win the battle but you really need to focus on the war, the war with Microsoft and if you don't you will be relegated to the dust bin.
The '90s called and said they want their battle-cry back.
Re: (Score:1)
OK, *you* fix Oracle's zFS licensing and the kernel team will accept zFS into the mainline kernel. Deal?
Re: (Score:2)
I guess someone has a reading comprehension problem.
Explain why that has to happen to get NFSv4 ACL support into the kernel - you know, like has existed in MacOS, Solaris, and FreeBSD for 20+ years?
Re: (Score:2)
It is time to take the tin foil hat off and think like a business person.
It's precisely the business person who is preventing OpenZFS adoption due to the legal uncertainty around the ZFS license from Oracle.
Re: (Score:2)
For a home lab, BTRFS is great and better in some ways to ZFS. No additional ram requirements, the ability to use mismatched size drives, etc.
The only downside I have run into is not being able to use raid 5.
Re: (Score:2)
NAS manufacturers use LVM to provide raid functionality for btrfs, rather than using the btrfs raid. It seems to work pretty well for them.
Re: (Score:2)
You think those are benefits, but they aren't. Particularly given btrfs's ability to nicely destroy even mirrored volumes. You've also got to consider the performance and general corruption problems with btrfs.
(ZFS can use 'mismatched sized drives' just fine.)
Re: (Score:2)
The existence is less about not invented here and more... wierd crap. Reiser... Oracle... ...and shit long development and testing cycles for file systems. I remember where we were supposed to be 20 years ago, and unfortunately, "lame but good enough" gets the critical mass and "logical" and "elegant" are pet projects.
Re: (Score:2)
"...so as to spite ZFS users."
Did you miss this part: "but licensing conflicts prevent ZFS being fully integrated into the Linux kernel."
Re: (Score:3)
Licensing prevents ZFS being fully integrated into the Linux kernel.
Does licensing force the kernel devs to deliberately break stuff to try make ZFS worse? It's one thing to not care about it and if it breaks it breaks, but it's another to deliberately break it.
It's like when Microsoft added a check to Windows 3.1 to throw an error if it detected that it was running on DR-DOS. Not just doing whatever and if DR-DOS does not have some functionality, well, whatever, but a deliberate artificial limit.
Re: (Score:2)
You didn't understand what I wrote.
I was tlaking about NFSv4 support, which the kernel team has not implemented. That's the gripe. Not ZFS "integration" into the kernel. It's just fine where it is.
Re: (Score:2)
apparently, that check was only in the pre-release evaluations copies.
But that was enough, because those copies were what journalists used to write the articles. Once the articles were out, the code had achieved its nefarious purpose.
Re: (Score:2)
ZFS licensing has absolutely zero to do with whether the Linux kernel supports NFSv4 ACLs - did you not read what I said?
It's literally the only operating system in use which doesn't have that support.
What's RedHat's take on bcachefs? (Score:4, Interesting)
Re: (Score:2)
red hat is working on their own.
Stratis
It's built on top of XFS but with COW abilities
Re:dont trust it? (Score:4, Informative)
Linux kernel releases are a funny experimental playing field now?
Yes, there are several steps: "Staging" (not merged http://www.kroah.com/log/linux... [kroah.com] ), "linux-next" (the latest version of Staging, close to be merged with Linus Thorvald's tree), then "Experimental" (released to regular users but scary warning when activating the option in "make menuconfig") After some time the maintainers may remove the "Experimental" warning. Today's news is bcachefs was released to the users with the "Experimental" tag.
Re: (Score:2)
now
Can you please elaborate on what you mean by "now"? I recall compiling my own kernels in the 90s where many of the possible options were marked as "(EXPERIMENTAL)".
Experimental components have always been part of the Linux kernel since its inception.
Bcache site says it's still beta... (Score:3)
I don't know that I trust a filesystem whose own FAQ says it's beta and not in the kernel.
https://bcachefs.org/FAQ/ [bcachefs.org]
"Is bcachefs stable for production use? Bcachefs can currently be considered beta quality. It has a small pool of outside users and has been stable for quite some time now; there's no reason to expect issues as long as you stick to the currently supported feature set."
"Is bcachefs included in the Linux kernel by default? Bcachefs is not yet upstream - you will have to build a kernel to use"
Re: (Score:3)
It is probably not compiled in by default and the kernel config option likely comes with a warning. All this means is that the kernel team now prepares to maintain it, it does not mean it is ready for production.
Re: (Score:1)
"Is bcachefs included in the Linux kernel by default? Bcachefs is not yet upstream - you will have to build a kernel to use"
This just hasn't been updated in the last 5 days. Also, it'll probably be a while before any distribution enables it -- so having to build a kernel to use a very new feature is kinda the deal. As of 6.7, bcachefs is supported by the kernel, but not by Debian or Redhat or Ubuntu or whoever.
Itanium the Denisovans of Computing. (Score:2)
Itanium never really took off and why Intel kept pushing it despite the XEON architecture just never made sense.