Announcement

Collapse
No announcement yet.

Bcachefs Submitted For Review - Next-Gen CoW File-System Aims For Mainline

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

  • #11
    bcache is super stable, bcachefs won't have the problems btrfs has (yes, has, not had). Because the model is sane, bcachefs is finally going to be COW, checksummed, and have acceleration topology of various disks. Have some old SSD you don't use? Add it and it's now a write landing zone, or a cache. Wow such smart.

    Comment


    • #12
      The Bcachefs kernel driver weighs in at around two thousand lines of code
      Michael

      The submitted patches are not a bcachefs driver, these are "all the non fs/bcachefs/ patches".

      No way on Earth a filesystem driver of such complexity could weigh in at 2 KLOC.
      Last edited by avis; 10 May 2023, 04:00 PM.

      Comment


      • #13
        I hope some btrfs (and ext4 ofc) to bcachefs migration tools will be prepared. I migrated to btrfs not so long ago using btrfs-convert without any problem.

        Comment


        • #14
          I'd wait to say it's super stable...just the fact that nobody uses it doesn't make it very stable, but when lots of users try it that's where you'll find out if it's that stable. This happens for any software and especially for file systems.

          Comment


          • #15
            As much as this might be great, no one is going to commercially use a one man created filesystem with a bus ratio of 1. There’s no support and no one to maintain it if something happens to the developer.

            xfs, btrfs and ext4 all have commercial support , there’s enough commercial usage (esp with xfs) that if need be someone will be paid to mantain it

            Comment


            • #16
              Originally posted by Britoid View Post
              As much as this might be great, no one is going to commercially use a one man created filesystem with a bus ratio of 1. There’s no support and no one to maintain it if something happens to the developer.
              The author clearly states I want bcachefs to outlast me - by making it the easiest filesystem for other developers to understand and work on. (on Patreon), It'll eventually gain attention.

              Edit: fix middle-click paste ugh

              Comment


              • #17
                Originally posted by Britoid View Post
                As much as this might be great, no one is going to commercially use a one man created filesystem with a bus ratio of 1. There’s no support and no one to maintain it if something happens to the developer.
                If the filesystem gets upstreamed, that may very well change quickly. For example, the patches submitted now includes some from Dave Chinner, prior upstream XFS maintainer and ongoing filesystems contributor from Red Hat. Now, it is entirely possible and even likely, this was done voluntarily and not on company direction but having a prominent filesystem developer who has commented positively about bcachefs having some contributions can build up to something more. These are just early stages. Major filesystems with advanced features typically take a decade or more to mature.

                Comment


                • #18
                  Originally posted by Beryesa View Post

                  The author clearly states I want bcachefs to outlast me - by making it the easiest filesystem for other developers to understand and work on. (on Patreon), It'll eventually gain attention.
                  Does it have a spec?

                  Comment


                  • #19
                    A bug list that's "too long" to enumerate is by no means "stable". Just because it gets included in Linus' tree doesn't make it "stable". Linus' tree itself is not stable. It regularly has data corrupting bugs and sometimes subtle errors that throw off calculations.


                    All that said, I'm more curious what bcachefs brings to the table in the form of minimizing write amplification on SSDs. We already have FS that do the listed features such as CoW, integrity hashing, etc, but only two that I'm aware of specifically address write amplification on flash media. Of those two, one highly recommends battery backed storage because it doesn't cover power loss scenarios since it was designed for smart phones and tablets.

                    Comment


                    • #20
                      Originally posted by zexelon View Post
                      specifically in a time period were RAID 5 was also a buzzword that everyone was jumping on... unfortunately this led to the discovery of a core design problem (that still exists today) in the RAID 5/6 implementation of BTRFS.
                      You mean a core design problem in RAID5.

                      What makes btrfs different is that btrfs developers actually loudly warn users about this RAID5 design flaw that is not specific to btrfs but to RAID5.

                      mdadm RAID5 also has the same issue, because it's an issue specific to RAID5 design, not the the implementation. The workaround provided by mdadm to that RAID5 design flaw is named ppl:

                      ppl For RAID5 only, Partial Parity Log is used to close the write hole and eliminate resync.
                      And that workaround is incredibly slow, defeating all the benefits of doing RAID5. If RAID5 requires ppl to be reliable, then no one has any usage for RAID5.

                      I don't know why this myth of “btrfs having flawed RAID5” is so much alive while it's RAID5 that is flawed to begin with, and that's not btrfs' fault.

                      If one does a RAID5 without using btrfs purposedly to avoid the flaws that btrfs RAID5 suffers from, that one is very likely running an as-much-flawed-RAID5 but without knowing it.

                      Illusion of security is worst than lack of security.

                      Comment

                      Working...
                      X