Announcement

Collapse
No announcement yet.

Bcachefs Completes Core Feature Work, Could Merge Soon If Review Goes Well

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

  • #11
    Originally posted by bitman View Post

    Now that would perform real fast. Not.
    There would be no discussion about this if we would be using microkernels.

    Comment


    • #12
      Originally posted by DoMiNeLa10 View Post

      There would be no discussion about this if we would be using microkernels.
      No doubt. Everything would be slow in such case.

      Comment


      • #13
        This is very exciting and Linux can use an alternative to ZFS and Btrfs. Especially if it turns out to be faster, it could become a preferred filesystem. RedHat or Canonical really should just hire him to continue to improve bcachefs including making sure that there is a working RAID56, that writable snapshots work well, that it can support multiple physical volumes being loaded into a volume group and having a feature like Btrfs's subvolumes.

        Comment


        • #14
          Originally posted by mmstick View Post
          Honestly, I'd rather that we move all file system drivers to user space.
          use hurd then

          Comment


          • #15
            basically, subj is at stage where btrfs was in 2008
            Originally posted by jpg44 View Post
            This is very exciting and Linux can use an alternative to ZFS and Btrfs.
            why another pile of bugs is so exciting?
            Originally posted by jpg44 View Post
            Especially if it turns out to be faster,
            and if not then what?
            Originally posted by jpg44 View Post
            it could become a preferred filesystem. RedHat or Canonical really should just hire him
            redhat could hire someone to work on btrfs. even some dozens of people instead of one. how does it work for redhat?
            Originally posted by jpg44 View Post
            to continue to improve bcachefs including making sure that there is a working RAID56, that writable snapshots work well, that it can support multiple physical volumes being loaded into a volume group and having a feature like Btrfs's subvolumes.
            so some idiot over internet is excited by thoughts of someone else pouring hundred man-years onto chasing already existing filesystem?

            Comment


            • #16
              Originally posted by bitman View Post

              Now that would perform real fast. Not.
              Honestly, I doubt there's any measurable difference. Placing drivers in the kernel doesn't magically make them faster, either.

              Comment


              • #17
                Originally posted by pal666 View Post
                basically, subj is at stage where btrfs was in 2008
                why another pile of bugs is so exciting?
                and if not then what?
                redhat could hire someone to work on btrfs. even some dozens of people instead of one. how does it work for redhat?

                so some idiot over internet is excited by thoughts of someone else pouring hundred man-years onto chasing already existing filesystem?
                There have been issues with btrfs. Overstreet explains this in his discussions about why bcachefs is worthwhile. btrfs code base is over-complicated and the filesystem is not necessarily easy to penetrate or maintain for outsiders. The filesystem is partiy a culture around its codebase and developers who are able to penetrate and understand its code so they can maintain it. That is, if a code base is extremely overly complex, it can be cheaper to re-implement than it is to try to fix it.

                Overstreet also is confident he can outdo btrfs on performance.

                bcachefs codebase has a different design characteristic that is easier for many developers to work on.

                The filesystem is based on existing bcache code in the kernel so the additional code to bring it to a full featured filesystem was not as great as a from scratch implementation.

                Comment


                • #18
                  I think the review thread on LKML is interesting mainly because (AIUI) Dave Chinner is telling Linus that a specific piece of (supposedly generic) kernel code for managing locks is broken enough that it's caused the xfs devs so much pain that Dave refuses to rely on it, while Linus wants it to be stress-tested and stabilised.

                  One could easily be led to suspect that perhaps the Linux kernel is -- to paraphrase the inimitable Eddie Izzard -- being held together by string, duct-tape and a note from Linus' mother.
                  Last edited by ermo; 11 June 2019, 07:43 PM.

                  Comment


                  • #19
                    Originally posted by Britoid View Post

                    Wasn't the functionality of bcache merged in with bcachefs?
                    Well bcache was the base of bcachefs so yes.
                    It might be feasible later to use bcachefs just for the features of bcache today, not sure, but the currents issues with bcache in master are completely not looked at by Kent anymore, and in one current issue a maintainer admitted not knowing enough to say much... This kind of stuff worries me for an fs....

                    Comment


                    • #20
                      have they fixed this bug yet?

                      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

                      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

                      Comment

                      Working...
                      X