Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Linux IT

Torvalds Calls For Calm as Bcachefs Filesystem Doesn't Make Linux 6.5 79

Posted by msmash from the tough-luck dept.
Linus Torvalds has delivered the first release candidate for version 6.5 of the Linux kernel, but warned this release may not go entirely smoothly. From a report: Torvalds's headline assessment of rc1 is "none of it looks hugely unusual." "The biggest single mention probably goes to what wasn't merged, with the bcachefs pull request resulting in a long thread (we didn't hit a hundred emails yet, but it's not far away)." As The Register reported in 2022, bcachefs is a filesystem that's been in development for nigh on a decade without being added to the kernel.

Kernel-watching outlet Phoronix on Sunday wrote that the filesystem is in good shape but debate over "code changes needed to the kernel outside of the kernel module itself" have proved contentious. As a result, conversation on the Linux kernel mailing list is "often becoming heated" when the topic turns to bcachefs. In his announcement post for rc1, Torvalds wrote "Let's calm this party down."
This discussion has been archived. No new comments can be posted.

Torvalds Calls For Calm as Bcachefs Filesystem Doesn't Make Linux 6.5 More

Torvalds Calls For Calm as Bcachefs Filesystem Doesn't Make Linux 6.5

Comments Filter:

  • Bcachefs (Score:2)

    by Anonymous Coward

    So I read their page and they claim to “a new advanced filesystem”.

    No thanks.

    Xfs and zfs have been in production for decades now. That’s why I trust them.

    • Re:Bcachefs (Score:5, Funny)

      by Paradise Pete ( 33184 ) on Monday July 10, 2023 @06:18PM (#63675529) Journal
      640 file systems should be enough for anybody.

    • Re:Bcachefs (Score:5, Interesting)

      by thegarbz ( 1787294 ) on Monday July 10, 2023 @06:33PM (#63675587)

      Reading one line from a page just leaves you more ignorant than not reading at all.
      a new advanced filesystem : It's called bcachefs because it is based on bcache, and shared a massive portion of its code base with it. It has been in the Linux kernel and in active use for over a decade. The only thing new here is that it adds a couple of very common file system elements to it.

      Xfs and zfs have been in production for decades now. : On the flip side the ZFS which you said has "been in production for decades now" most definitely has not been in production for decades on Linux. The stable version of the ZFS kernel module was released only a decade ago. The version compatible with oracle was made stable in 2014 (less than a decade), and as of writing this post ZFS is *not* natively part of the Linux kernel and *not* maintained by the kernel team.

      And XFS is a journaling file system, completely different beast with different pros and cons that a sensible person would weigh up against alternatives, rather than just going with "it's old so I trust it".

    • Imagine thinking that we should stop all progress now. You're the guy in 1900 arguing against electricity.

  • There's already a dozen filesystems that I don't use, what makes this one special?

    Seriously, even after reading the FAQ on their website, I don't see why I should care about this one; somebody explain why I should ?

    • duh (Score:1)

      by Anonymous Coward
      It validates the feelings of the people who have been working on it. That is the problem with open-source software -- too many people see it as a way to validate their egos by making changes.

    • Re:Why do I care? (Score:5, Interesting)

      by silvergig ( 7651900 ) on Monday July 10, 2023 @06:23PM (#63675543)

      There's already a dozen filesystems that I don't use, what makes this one special?

      Seriously, even after reading the FAQ on their website, I don't see why I should care about this one; somebody explain why I should ?

      Because this is a filesystem that is backed by bcache, which is a read and write caching kernel module, that can add some considerable speed up.......but here's the thing, you can use bcache as a block cache behind any filesystem, including xfs and zfs, or ext4, so you can get the benefits of write/read caching on the filesystem that you are already comfortable using, which is how I have always used it.

      I get it that many people want to have their name in lights as an FS dev, but honestly, bcache is a great module by itself and is maintained by a group of people, not just one person. Bcachefs just sounds dangerous because as far as I know, it has one dev. That makes it a non-started for anything important.

      • Re: (Score:2)

        by pz ( 113803 )

        I've lost you somewhere.

        bcache is a great kernel module that is in widespread use, as far as I can tell, and does a great job of using otherwise unused RAM for a disk cash no matter what sort of file system is being used. Total win.

        But why does that make bcachfs a good idea? What I am missing?

        • Re: (Score:2)

          by PCM2 ( 4486 )

          But why does that make bcachfs a good idea? What I am missing?

          I think you're missing the part where the Parent said "Bcachefs just sounds dangerous because as far as I know, it has one dev.."

        • bcache is about using a fast drive (SSD) as cache. Not RAM.
          The OS already use unused RAM as cache, but it is lost on reboot and usually very limited.

      • but here's the thing, you can use bcache as a block cache behind any filesystem, including xfs and zfs, or ext4

        ZFS already has native caching as well in the form of L1 and L2 ARC. I'm not clued in enough to understand if this would provide any benefit over that.

    • You know, I've long been a proponent for building something even if a hundred other of it exist. For whatever reason... the fun? the education? Incidentally, I feel Linux is the perfect candidate for these sorts of things.

      BUT... why the need to have it merged into Linux's main branch?\

      So I guess I'm with ya! =)

      • Re: (Score:2)

        by Shaitan ( 22585 )

        Merging into the kernel is the whole idea. The FS has similar capabilities to ZFS but ZFS comes with a license that prevents it from being a native kernel integrated FS.

    • There's already a dozen filesystems that I don't use, what makes this one special?

      It seems to have the feature I wanted for years: being able to use a fast drive (think NVME SSD) as a cache for larger but slower drive (HDD or maybe even SATA SSD). And not have to micromanage which files or program should be installed on the SSD and which one should be on the HDD.
      And as a bonus, you can specify you always want a minimum of 2 copies of each file (think of it as RAID1), so that it continue to work even if any drive fails.

      bcache seems to be doing it at the block level, but it's much better t

      • Re: (Score:2)

        by dnaumov ( 453672 )

        This has been doable in ZFS (l2arc) for god knows how damn long.

        • But ZFS is not in the Linux kernel, and will always suck because of that, except for some specific scenarios. As a root/boot filesystem, it's not very good.
          If you have a single purpose system which is to store data (think of it as NAS or fileserver) then ZFS can be considered, but otherwise I don't think it's worth it.

          • You can use FreeBSD for a lot more than a NAS.

            The way I look at things, Linux is limited because it does not ship with ZFS. Looking at ZFS as the limitation is backwards.

            • There is a lot more to an OS than a filesystem. ZFS isn't worth switching OS except maybe for some very specific use cases. But yes, I guess I would rather use FreeBSD than Solaris if I wanted ZFS so badly.

              To me ext4 + mdadm raid is good enough, and is very stable.

    • I'm still scanning the headlines half expecting to see an announcement for ext5....

    • Re: (Score:2)

      by jwhyche ( 6192 )

      There's already a dozen filesystems that I don't use, what makes this one special?

      I find that vanity file systems tend to come with resume generating events. Run your vanity filesystem on your personal pie box but keep it away from my servers.

      • It's not just a new filesystem. It is a paradigm shift due to the arrival of SSDs. Think persistent file system caching: caching happens in SSD not RAM so it survives across reboots.

        Plus it can be used behind existing filesystems.

    • THIS. I mean they can't even properly articulate what is wrong with BTRFS RAID5/6 (which are for many use cases the right levels) code (probably not much if not used for metadata), never mind having a concrete list of tickets against it, never mind actually working on them. We just have the same dull warning "don't use it" since 2017. There just isn't any love for storage in general, if it works as it is, with ext4/xfs level features, fine, move along.

    • Re: (Score:2)

      by Shaitan ( 22585 )

      It has most of the capabilities of ZFS without having a license that precludes it from being integrated into the kernel. So no false massive memory usage reports, you can use it as a root/boot drive, etc.

  • Missing info. (Score:3)

    by MachineShedFred ( 621896 ) on Monday July 10, 2023 @06:22PM (#63675537) Journal

    How about including a small blurb on what the fuck "bcachefs" is and why anyone should care that is isn't included in a release candidate kernel?

    Seriously, I'm not going to go look up data on file systems that developers can't even come to consensus on if it should be included or not. What does "bcachefs" bring to the table that we aren't already getting from ZFS or XFS if EXT4 isn't good enough?

    Was it at designed in large part by a murderer like a fancy new filesystem we heard about a few years ago, and is now a relic of a bygone era?

    • Re:Missing info. (Score:5, Informative)

      by Firethorn ( 177587 ) on Monday July 10, 2023 @06:27PM (#63675559) Homepage Journal

      https://bcachefs.org/ [bcachefs.org]

      Well, a quick summary, it seems to be supporting all the latest hotness desired in file systems today.
      Feature set:
      Copy on write (COW) - like zfs or btrfs
      Full data and metadata checksumming
      Multiple devices
      Replication
      Erasure coding (only feature not quite stable)
      Caching
      Compression
      Encryption
      Snapshots
      Scalable - has been tested to 50+ TB, will eventually scale far higher

      • Re:Missing info. (Score:5, Interesting)

        by ArchieBunker ( 132337 ) on Monday July 10, 2023 @06:36PM (#63675597)

        50TB isn't that much these days. WD is selling 22TB drives right now.

      • >"Well, a quick summary, it seems to be supporting all the latest hotness desired in file systems today. Feature set:"

        Yeah, but the real question is- what does it do better than, say, ZFS, for example?

        I looked around and didn't find much of anything useful except a few benchmarks showing it SLOWER than ZFS, Btrfs, and XFS. Another recent posting says "Bcachefs is still missing scrub and the ability to easily replace devices."

        • You hit the nail on the head. I much rather see fscrypt() support in btrfs mainlined, because btrfs is a solid filesystem [1], definitely behind ZFS, but due to licensing, this is understandable. fscrypt() would allow btrfs to have native encryption without needing a LUKS layer underneath it, or mount another filesystem like eCryptFS or CryFS on top.

          Times have changed, and enterprise filesystems have features that people expect. One of those is checksumming so that bit-rot is detected, if not repaired.

          • One correction: I didn't intend to state bcachefs didn't have features like checksumming and encryption. However, the ability to do scrubs is one that one almost assumes goes with checksumming.

          • because btrfs is a solid filesystem [1], definitely behind ZFS, but due to licensing, this is understandable.

            It's not understandable. This is:

            WTF does "the licensing" have to do with this? OSS has thousands of fabulous developers. You can't go the rest of your lives blaming the evil Larry because linux has a feature but it's behind some other's feature who doesn't want to give Linux the code. Every time you use that license crutch you're shitting on the efforts and abilities of your "own" devs. Can't you idiots see that? Maybe time to ditch your benevolent dictator cult and loosen the dev's creativity. Bunch of p

            • It is less about the license, than license conflicts. If the code can be mainlined, that will go a lot further, than having to install a third party package. Especially in commercial environments, where if one does use a package not with the OS, there isn't any support for it, and this can have dire consequences in some environments. Having ZFS as part of the default OS allows it to be used in production, with a "throat to choke" if something happens, which is important come audit time.

              And it isn't like

      • https://bcachefs.org/ [bcachefs.org]

        Erasure coding (only feature not quite stable)

        And this inspires confidence, how?

      • LOL. We run at least hundreds (if not thousands) of ext4 filesystems that are 1 PB or larger. If bcachefs is struggling with 50TB today, it has some pretty serious design and/or implementation issues.

        • You're not running ext4 on PB hardware. Something else is managing your disks.

        • it is *not* struggling with 50TB

          It's coping fine and is *expected* to scale much further but hasn't been tested there. Some dude has worked on it and maintained it as an out-of-kernel component for years and now it's close to getting it merged into mainline, which would make life easier for the developer and *much* easier for potential testers/adopters, including those with petabytes of disks.

          For some reason the merge triggerd a shitstorm of abuse so that Linus T called for calm, that's all.

          there's a grea

      • Scalable - has been tested to 50+ TB, will eventually scale far higher

        Damn! My puny home server has more than that.

    • What does "bcachefs" bring to the table that we aren't already getting from ZFS or XFS if EXT4 isn't good enough?

      ZFS isn't in mainline Linux, and never will be unless Oracle changes the license, but you could have said btrfs instead. The answer appears to be caching. And also, they pretend that bcachefs doesn't eat your data (so btrfs does?)

    • How about including a small blurb on what the fuck "bcachefs" is and why anyone should care that is isn't included in a release candidate kernel?

      I think a small blurb that says "Nobody cares about you boasting about not knowing things. Google exists" might be more compact.

      • Yeah, god forbid that on a site that focuses on technology news might actually include a brief synopsis of the technology in question in the summary about that technology not being included in the Linux kernel, especially if it's a project the vast majority of people around here haven't even heard of before.

        You know, just to be able to include and engage more of the ever-dwindling readership around here. And maybe do a little bit to hit the brakes on the slow-motion collapse of this once great site.

        • You know, just to be able to include and engage more of the ever-dwindling readership around here.

          I've been seeing a lot of old people return these last few weeks. Wonder what happened...

  • For those who haven't read the Linux Kernel Mailing List and haven't kept up with the discussions: BcacheFS has been in the works for a while, but it still needs some work before it's inducted into the main Linux Kernel Project. What people are objecting to, is that his patches are touching things outside of bcache. When that sort of thing happens, maintainers often don't like other devs trying to make changes to the projects they handle. There is supposedly some personal drama between the bcachefs dev

    • Yup. Changing relatively mature parts of the kernel outside of bcachefs causes a risk of regressions that could impact other filesystems, and perhaps even result in data loss. No one wants that.

      Better approach: take your time, work with the maintainers of these other kernel subsystems, try not to change how any APIs/syscalls work unless it can be done with extreme safety, BUT, perhaps, add new APIs/syscalls that would meet the needs of bcachefs with relatively minimal risk of regressions.

      And I suspect tha

      • Some of these are required changes outside the tree, such as exposing primitives or other include file changes.

        Other changes are due to technical debt in the current mainline, such as the passing around of callback functions up the wazoo which simply doesn't scale and needs to be addressed anyway. Bcachefs doesn't address these but it does need to work around them and that requires out-of-tree changes.

        Obviously the VFS maintainers are not happy, the whole point of VFS is to not expose primitives that allow

  • I like how Torvalds is a natural boss of Linux. Only makes me worried , what happens after he 'leaves' - sooner or later (Yes - people age and die). Might put whole project under risk ,as I dont see any corporate CEO / CTO , that changes jobs every once in a while for paycheck, can do this job.

    • Re: (Score:2)

      by vbdasc ( 146051 )

      He said 'Let's calm down'. He's getting old...

      • Re: (Score:2)

        by Entrope ( 68843 )

        Technically, he wrote "Let's calm this party down." I took that to be a shorter, less harsh way of saying "Cease this abject tomfoolery lest I don yonder boots, which are made for kicking, to make some pointed interjections."

    • I'm a little older than Mr. Torvalds, and in poor health, and desperately trying to convince people to find my eventual replacement(s) so I can train them while I still can.

      Also trying desperately to teach my wife and kids how to do the things I usually do for them, so those things still get done after I'm too old or sick or dead to be able to do them anymore.

      I think those are things that anyone in late middle age should be thinking about. We do not live forever, and the important things that we do will st

  • I understand how they arrived at that name, however, it's a terrible fucking name - like most of Linux.

Slashdot Top Deals

"To take a significant step forward, you must make a series of finite improvements." -- Donald J. Atwood, General Motors

Close