Announcement

Collapse
No announcement yet.

Bcachefs Linux File-System Seeing Performance Improvements, Other Progress

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

  • Bcachefs Linux File-System Seeing Performance Improvements, Other Progress

    Phoronix: Bcachefs Linux File-System Seeing Performance Improvements, Other Progress

    While Ubuntu continues in their path of OpenZFS integration, Fedora is revisiting the possibility of using Btrfs on the desktop, Red Hat is continuing to invest in Stratis, and Reiser5 is being developed, Bcachefs as the file-system born out of the Linux block cache code is continuing to evolve...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Certainly good to see such a variety of filesystems which also helps people choose one which works best for them. I hope bcachefs gets mainlined soon. Also good to see ReiserFS continuing although maybe they should consider a rebranding at this point.

    Comment


    • #3
      Another sad overhyped failsystem. I like especially how the slogan for this FS is "the COW filesystem that won't eat your data", yet a couple of paragraphs into the introduction this promise is watered down to mere "bcache already has a reasonably good track record for reliability". Maybe they should rebrand as "the COW filesystem that won't, most of the time, eat your data".

      Let's say I wouldn't host even my browser history on a disk partition running BcacheFS.
      Last edited by curfew; 28 June 2020, 11:18 PM.

      Comment


      • #4
        Just talking about my own experience here, bcachefs might be overhyped on its stability promises, but at least in my own testing I've never lost any data on it. btrfs on the other hand has a 100% failure rate in my experience. Literally every single time I'd heard enough good news about btrfs to trigger me into giving it another try, I'd run into corrupted filesystem data. So at least in my own experiments bcachefs has proven more stable than btrfs and in fact btrfs has proven to be the most unreliable filesystem of -all- time.

        Comment


        • #5
          Originally posted by curfew View Post
          Another sad overhyped failsystem. I like especially how the slogan for this FS is "the COW filesystem that won't eat your data", yet a couple of paragraphs into the introduction this promise is watered down to mere "bcache already has a reasonably good track record for reliability". Maybe they should rebrand as "the COW filesystem that won't, most of the time, eat your data".

          Let's say I wouldn't host even my browser history on a disk partition running BcacheFS.
          You are overexaggerating in an attempt to appear knowledgeable and relevant.

          First, the reliability track record was about bcache, not bcachefs.

          Second. The filesystem is under development, pre-release, v0.0.0, whatever else do you call it. The "won't eat your data" part relates to its architecture and development model — which, by author's intention, will translate to better reliability once the major groundlaying development is done and the filesystem is actually released.
          Last edited by intelfx; 29 June 2020, 01:47 AM.

          Comment


          • #6
            Originally posted by duby229 View Post
            btrfs on the other hand has a 100% failure rate in my experience. Literally every single time I'd heard enough good news about btrfs to trigger me into giving it another try, I'd run into corrupted filesystem data.
            Sounds like a PEBKAC problem to me. I've been running btrfs for 8+ years with zero problems.

            Originally posted by intelfx View Post
            You are overexaggerating in an attempt to appear knowledgeable and relevant.
            I've noticed the same thing about bcachefs though. The developer has been quite critical of other filesystems, but he's always full of pure marketing hyperbole when speaking about his own code. You can't get a well balanced perspective on how "reliable" a filesystem is just by listening to the developer's own hype about it. Especially when he's collecting donations, largely motivated by said hype.

            The last mainlining attempt for bcachefs was titled something like "alright this thing has finished cooking, let's get it mainlined!". He then submitted dozens of patches with stale commit messages and completely botched rebases. I wonder how much of that same ineptitude finds its way into the actual code.

            Some people are so gullible that they just jump from one hype train to the next. I bet you're also a Rust evangelist...
            Last edited by JustinTurdeau; 29 June 2020, 02:38 AM.

            Comment


            • #7
              Originally posted by JustinTurdeau View Post
              He then submitted dozens of patches with stale commit messages and completely botched rebases. I wonder how much of that same ineptitude finds its way into the actual code.
              You do realize, right, that writing code and navigating the LKML procedural bureaucracy are two different things? If you never submitted code to the Linux kernel upstream, I'd wager 99% that you will completely mess it up when you try.

              Originally posted by JustinTurdeau View Post
              Some people are so gullible that they just jump from one hype train to the next. I bet you're also a Rust evangelist...
              Easy with the insults. And you bet wrong. As a matter of fact I don't use bcachefs at all (and neither I do Rust, although I'm very much looking forward to evaluating both, when they gain specific features I would like to have at my disposal).

              Comment


              • #8
                Originally posted by intelfx View Post
                You do realize, right, that writing code and navigating the LKML procedural bureaucracy are two different things? If you never submitted code to the Linux kernel upstream, I'd wager 99% that you will completely mess it up when you try.
                I have submitted code to the Linux kernel. It's barely any different than any other large scale project of that kind. The fact you don't realize this means there's a 99% likelihood that you're speaking as someone who's never submitted anything.

                Here's Linus' response to the last mainlining attempt:

                There are obvious things wrong with it - like the fact that you've rebased it so that the original history is gone, yet you've not actually *fixed* the history, so you find things like reverts of commits that should simply have been removed, and fixes for things that should just have been fixed in the original commit the fix is for.

                And this isn't just "if you rebase, just fix things". You have actual bogus commit messages as a result of this all.

                So to point at the revert, for example. The commit message is

                This reverts commit 36f389604294dfc953e6f5624ceb683818d32f28.

                which is wrong to begin with - you should always explain *why* the revert was done, not just state that it's a revert.

                But since you rebased things, that commit 36f3896042 doesn't exist any more to begin with. So now you have a revert commit that doesn't explain why it reverts things, but the only thing it *does* say is simply wrong and pointless.

                Some of the "fixes" commits have the exact same issue - they say things like

                gc lock must be held while invalidating buckets - fixes "1f7a95698e bcachefs: Invalidate buckets when writing to alloc btree" and fixes b0f3e786995cb3b12975503f963e469db5a4f09b

                both of which are dead and stale git object pointers since the commits in question got rebased and have some other hash these days.

                ...

                Anyway, aside from that, I only looked at the non-bcachefs parts. Some of those are not acceptable either ...
                That is straight up incompetence, not some kind of honest mistake made while navigating the "procedural bureaucracy".

                I'm not trying to shit on his efforts or say the filesystem is bad. I'm just serving as a much needed reality check. What a developer says about his own code (which has already attracted $2k/month in donations) and hard, cold reality are two completely different things. He's always going to talk it up and compare it favourably to the competition, for reasons that should be obvious.
                Last edited by JustinTurdeau; 29 June 2020, 03:46 AM.

                Comment


                • #9
                  I'd prefer if he would put more effort towards getting it included in the kernel.
                  Imho one dev is not enough for a filesystem. Its to critical and needs reviews.

                  That said i actually like bcachefs and would like to use it.

                  Comment


                  • #10
                    Originally posted by curfew View Post
                    Another sad overhyped failsystem. I like especially how the slogan for this FS is "the COW filesystem that won't eat your data", yet a couple of paragraphs into the introduction this promise is watered down to mere "bcache already has a reasonably good track record for reliability". Maybe they should rebrand as "the COW filesystem that won't, most of the time, eat your data".

                    Let's say I wouldn't host even my browser history on a disk partition running BcacheFS.
                    Filesystems in development aren't finished yet, more news at 20:00

                    Comment

                    Working...
                    X