Announcement

Collapse
No announcement yet.

Bcachefs Rolling Out New Allocator, Performance Continues Improving

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Bcachefs Rolling Out New Allocator, Performance Continues Improving

    Phoronix: Bcachefs Rolling Out New Allocator, Performance Continues Improving

    Bcachefs developer Kent Overstreet on Friday published a new status update on this original file-system born out of Linux's block cache (BCache) code. Bcachefs has been in development for years though it isn't quite yet in a position for landing in the mainline kernel. In any event a lot of feature work continues happening and Overstreet remains dedicated to the file-system's success...

    https://www.phoronix.com/news/Bcache...x-October-2022

  • #2
    Some 9 years after Bcachefs kicked off in 2013 (based on rather solid ground of Bcache) we're still nowhere near anything usable.

    Yet some people keep holding their breath waiting for it to beat the crap out of btrfs.

    Meanwhile btrfs started from scratch in 2007 and btrfs 1.0 got included into mainline kernel in 2009.
    In 2012 Oracle Linux and SUSE removed experimental flagging and started offering production level support.
    At 8 years in 2015 it became the default filesystem of SUSE distribution.

    While the wait for anything besides copium regarding to Bcachefs is likely to continue some more.
    Last edited by pkese; 29 October 2022, 07:27 AM.

    Comment


    • #3
      P.S.
      The above is not criticism of Bcachefs or Kent Overstreet. In fact I admire his knowledge and engineering.
      It is pointed at people having irrational positive/negative attitudes balanced between Bcachefs and btrfs.

      Comment


      • #4
        Originally posted by pkese View Post
        P.S.
        The above is not criticism of Bcachefs or Kent Overstreet. In fact I admire his knowledge and engineering.
        It is pointed at people having irrational positive/negative attitudes balanced between Bcachefs and btrfs.
        I mean, one negative of BTRFS is including it so quickly in the kernel soured the kernel devs on any other FS that wasn't battle tested, such as BCacheFS and Tux whatever that other one was.

        Comment


        • #5
          How many people work on this FS, and how many corporations back this effort? Since BTRFS had much more of both resources from the beginning, the comparatively slow pace should not be surprising...

          Comment


          • #6
            Originally posted by MauganRa View Post
            How many people work on this FS, and how many corporations back this effort? Since BTRFS had much more of both resources from the beginning, the comparatively slow pace should not be surprising...
            We can say that filesystems are very complicated and take a long time to develop to a point where they are reliable. Yet one thing that always puzzles me is the HAMMER filesystem, which came out of nowhere from the same developer who was working on a complete BSD operating system.

            Comment


            • #7
              Originally posted by pkese View Post
              Some 9 years after Bcachefs kicked off in 2013 (based on rather solid ground of Bcache) we're still nowhere near anything usable.

              Yet some people keep holding their breath waiting for it to beat the crap out of btrfs.

              Meanwhile btrfs started from scratch in 2007 and btrfs 1.0 got included into mainline kernel in 2009.
              In 2012 Oracle Linux and SUSE removed experimental flagging and started offering production level support.
              At 8 years in 2015 it became the default filesystem of SUSE distribution.

              While the wait for anything besides copium regarding to Bcachefs is likely to continue some more.
              I agree it is silly to expect raw performance for bcachefs to dominate. Even if bcachefs has a better design, it will take years of optimization, and that is not as important as avoiding pathological performance issues, and general stability/robustness.

              The timeline for bcachefs is somewhat disappointing. I was a btrfs fanboy ever since Valarie's article here https://lwn.net/Articles/342892/ , but after many struggles with it, I looked for the next thing, even while continuing to use btrfs. I still use btrfs, but avoid using snapshots, even though I would love to use them, because I consider btrfs still somewhat fragile when using advanced features. And that is with years of heavy facebook/suse engineering work.

              With bcachefs, I do think Kent has dragged things on a bit too long. His attitude of "I have enough bugs to fix even without upstreaming" and upstream's "stabilize the disk format before upstreaming" just doesn't bring the right focus. bcachefs will never be successful without more then Kent working on it, so I think the issue is really Kent having some sort of separation anxiety. Of course, in the meantime, he has put a lot of effort into debugging bcachefs faults, as well as the ecosystem for fault and stress testing filesystems is a lot better today then it was fifteen years ago.

              I think the best course of action is to upstream immediately, ensure no one uses the filesystem other then testers with some mandatory "--wreck-my-data" mkfs option, and hope that the developers come that are needed to sustain bcachefs' future. I've been a patreon supporter of this project for years, and I haven't even created one bcachefs filesystem. Perhaps it's time for me to reevaluate that.

              Comment


              • #8
                I am biased towards BTRFS , but I hope Bcachefs really turns out to something more than a research project. That being said it is perhaps a bit strange that a filesystem which apparently was better designed than BTRFS is still being reworked which of course may introduce new bugs. Sure this things happens on BTRFS as well (extent tree V2) but since Kent complained so clearly about all the wrong design choices BTRFS did it is a bit surprising to see this so late. Perhaps a bit eager there Mr. Overstreet?

                http://www.dirtcellar.net

                Comment


                • #9
                  I'm impressed how mostly a single person was able to come up with all of this and create all the needed code.

                  btrfs has many more developers and every few years I test to see how easy it is to use for RAID1 for / on 2 devices and every time I look up the manual pages and test and doesn't work. I just tried it again and it didn't. Very disappointing. Pretty simple test: install a Linux distribution with btrfs, add a second device and convert to raid1 and run balance, etc. and then run grub-install on the second device and shutdown, remove the first device and boot from the second (possibly with extra boot flags, etc.) but I can't even simply mount it from initramfs. So seems to me they made it all to complicated to be able to get this simple use case to work. In the past also asked something like that the mainlinglist, no answers. So why should I trust my data to it ? Or can anyone tell me how I should have done ?
                  Last edited by Lennie; 29 October 2022, 02:10 PM.

                  Comment


                  • #10
                    As much as these efforts are cool and I’m always keen to see new and better FS… the pace of development makes it seem like this will never actually mainline and the lack of funding implies that the enterprise/pro world do not rate it.

                    I think an equally large issue is that btrfs, ZFS, XFS, etc seem to be making rapid gains and improvements with every kernel cycle.

                    Comment

                    Working...
                    X