Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Linux

Biggest Linux Kernel Release Ever Welcomes bcachefs File System, Jettisons Itanium (theregister.com) 52

Posted by BeauHD from the welcome-aboard dept.
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.
This discussion has been archived. No new comments can be posted.

Biggest Linux Kernel Release Ever Welcomes bcachefs File System, Jettisons Itanium More

Biggest Linux Kernel Release Ever Welcomes bcachefs File System, Jettisons Itanium

Comments Filter:

  • Jettisons Itanium? (Score:4, Interesting)

    by guruevi ( 827432 ) on Thursday January 11, 2024 @05:50PM (#64151239)

    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)

      by test321 ( 8891681 ) on Thursday January 11, 2024 @06:04PM (#64151279)

      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)

      by Gavino ( 560149 ) on Thursday January 11, 2024 @06:06PM (#64151285)
      PowerPC and MIPS aren't actually dead architectures. MIPS still gets used in the embedded space, and POWER is still evolving and coming out with new stuff. Itanium's only maker was Intel, and they buried it years ago. It's dead, Jim. As for support - any architecture that uses Itanium is old and doesn't need the latest kernel. There are LTS kernels that will be supported beyond 2025 that will still have Itanium, and HP can always maintain one of those branches with backports if they are contractually obliged to. Nothing to see here, move along.

    • > 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)

      by batkiwi ( 137781 ) on Thursday January 11, 2024 @06:45PM (#64151391)

      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 ......

    • Itanium chips will be fab'd until 2025 at which point I expect HPE to run away screaming from the entire ISA given it's failure and extremely fraught legal history. EPIC, the Itanium ISA, was doomed after the promised compilers failed to materialize. Intel's technical bench just wasn't strong enough to get the compiler working at anywhere near it's boasted potential. Linux runs on Itanium so painfully slow I honestly wonder if it wouldn't get stomped by a Pentium 60. I might be exaggerating a little, but it

    • Re:Jettisons Itanium? (Score:4, Informative)

      by fuzzyfuzzyfungus ( 1223518 ) on Thursday January 11, 2024 @09:01PM (#64151631) Journal
      There will probably be Itanium users for a while; but only the ones who have some legacy workload that absolutely cannot be touched for some reason or another.

      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)

      by Lproven ( 6030 )

      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)

        by guruevi ( 827432 )

        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)

    by CAIMLAS ( 41445 ) on Thursday January 11, 2024 @05:52PM (#64151245)

    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)

      by suutar ( 1860506 ) on Thursday January 11, 2024 @06:08PM (#64151293)

      That may also come back to the licensing issues, especially if it came from Oracle ZFS.

    • Re:Frustrating (Score:5, Informative)

      by Tailhook ( 98486 ) on Thursday January 11, 2024 @06:33PM (#64151365)

      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.

    • 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)

      by MightyMartian ( 840721 ) on Thursday January 11, 2024 @07:53PM (#64151527) Journal

      Oracle is the one creating the uncertainty of a potential hostile environment. Quit blaming the kernel team for yet another hostile corporation.

      • Re: (Score:3)

        by CAIMLAS ( 41445 )

        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

    • 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)

      by arfonrg ( 81735 )

      "...so as to spite ZFS users."

      Did you miss this part: "but licensing conflicts prevent ZFS being fully integrated into the Linux kernel."

      • 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)

          by CAIMLAS ( 41445 )

          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)

          by hawk ( 1151 )

          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)

        by CAIMLAS ( 41445 )

        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)

    by Gavino ( 560149 ) on Thursday January 11, 2024 @05:59PM (#64151267)
    Since RedHat seemed to be the most high-profile critic of Btrfs, I'd love to hear their views on the matter, especially given that they, unlike Ubuntu, have stayed away from ZFS. Could this be the COW filesystem that RedHat invests heavily into? That would be pretty exciting for Linux, as having RedHat's development weight behind it would be a real boon. I'm a long-time user of ZFS, but it not being in the kernel is a little concerning. I was interested in Btrfs at one stage but it does seem that many people far more knowledgeable than me feel that Btrfs has fundamental design flaws. I really hope that bcachefs fulfills everyone's needs, and that it can be the COW filesystem that unites us all. So is RedHat going to get behind this one or not?

  • Bcache site says it's still beta... (Score:3)

    by batkiwi ( 137781 ) on Thursday January 11, 2024 @08:37PM (#64151591)

    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)

      by gweihir ( 88907 )

      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)

      by wed128 ( 722152 )

      "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 never really took off and why Intel kept pushing it despite the XEON architecture just never made sense.

Slashdot Top Deals

news: gotcha

Close