Announcement

Collapse
No announcement yet.

Bcachefs Fixes Pull Once Again Frustrates Linus Torvalds - Two Choices Offered

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

  • Originally posted by Alexmitter View Post
    ...Yet he pushes code that didn't even work with the damn automated linux build bot on all architectures. If hes that good, he would not make absolute beginner mistakes.
    Uh, to be fair, I don't think writing C code that works identically on x86 / amd64 / arm / arm64 / alpha / m68k / s390 / s390x / mips / powerpc / riscv / sparc is something that falls in the "beginner" category - unless you expect all beginners to have access to all the platforms and be able to debug all of them proficently. That is what the CI infrastructure is there for, and why it was a sarcastic target earlier in this thread; _very few_ are expected in this category, certainly not beginners.

    Comment


    • Originally posted by Alexmitter View Post
      Hes a egoistic one man show who build a filesystem ontop of the existing bcache code
      Bcache is from that same person and it is allready in the kernel All About the Linux Kernel: Bcache - Linux.com

      So why is Bcachefs the next version bad now ?

      Have to download the newest kernel source and look if bcache is marked experimental maybe it is.

      Comment


      • Originally posted by TheMightyBuzzard View Post

        This will become arguably true when they can go three years without using the word "corruption" (or any synonym) in the btrfs changelog. Until then, it's not even a debate; you're just wrong.
        It may be a insane thing to conclude for a "whatever the current messiah filesystem is" fanboy like you, but maybe, just maybe, they still work on those shortcomings btrfs has, like RAID5/6, as the manual clearly states. Get over yourself.

        Comment


        • Originally posted by browseria View Post

          Uh, to be fair, I don't think writing C code that works identically on x86 / amd64 / arm / arm64 / alpha / m68k / s390 / s390x / mips / powerpc / riscv / sparc is something that falls in the "beginner" category - unless you expect all beginners to have access to all the platforms and be able to debug all of them proficently. That is what the CI infrastructure is there for, and why it was a sarcastic target earlier in this thread; _very few_ are expected in this category, certainly not beginners.
          Its not writing portable C code which is the beginner part here, everyone makes mistakes. Its letting the automated Linux build bot do its testing before submitting. Who cares for Kents shitty CI that cares about his filesystem and nothing else but as always Kent knows it better.

          Comment


          • Originally posted by Alexmitter View Post
            When was that, in 2009...
            For me, it was just last month. On a Fedora Linux 38 system that was updated to Fedora Linux 40 as each new release went GA. On Kabylake hardware with NVMe. There are still problems with BTRFS. Ignoring them doesn't make it less true.

            Comment


            • Originally posted by Alexmitter View Post

              It may be a insane thing to conclude for a "whatever the current messiah filesystem is" fanboy like you, but maybe, just maybe, they still work on those shortcomings btrfs has, like RAID5/6, as the manual clearly states. Get over yourself.
              Barking up the wrong tree, bud. I don't use experimental filesystems in production. Period. Stable or GTFO.

              Comment


              • Of all the experts who have opined in this thread, how many have written, pushed and have merged at least a single patch for the Linux kernel?

                My guess is zero.

                How many have maintained such a huge and complex codebase?

                No guesses, it's ZERO.

                Linus and Kent will figure it out. Hopefully Bcachefs won't get booted. I just wanted to say the Linux kernels releases cadence is quite hard to work with.

                Comment


                • Originally posted by Alexmitter View Post

                  So he once worked for a company that does data storage. Nice. Too bad they don't sponsor his work, like any other company in that space. He only has private zfs fanboys donating on patreon.
                  They do sponsor his work, read the ml


                  Originally posted by Alexmitter View Post
                  As the manual states. btrfs' incomplete state on RAID5/6 are no secret. Other filesystems spottiness in terms of file safety on RAID5/6 are also no secret. Those modes simply require special care on all filesystems.
                  It was a secret for 10 years unless you manually trawled through the mailing lists. As I said, the warning was just added 2 years ago.

                  Also OpenZFS does not have the write hole, it works perfectly fine for RAID 5/6 setups (i.e. zraid1/zraid2). This is a verifiable fact because zfs designed the on disk format to handle this case where as btrfs did not (thats why the issue has been unsolved in btrfs, for btrfs to properly fix the issue they have to make a breaking change to the on disk format)


                  Originally posted by Alexmitter View Post
                  If you believe your data is safe on ZFS or even on bcachefs in its current state (clownface) in RAID5/6, then good for you, i'll go laugh my ass off.
                  It is, openzfs has solved the write hole issue. Please educate yourself and go read https://openzfs.github.io/openzfs-do...pts/RAIDZ.html and https://www.open-e.com/blog/data-integrity-raidz/

                  Comment


                  • Originally posted by Alexmitter View Post
                    Its not writing portable C code which is the beginner part here, everyone makes mistakes. Its letting the automated Linux build bot do its testing before submitting. Who cares for Kents shitty CI that cares about his filesystem and nothing else but as always Kent knows it better.
                    Which was the entire point of the article. I think everyone can agree that pushing forward without following the process - which includes getting built by the automated Linux build bot - was wrong and something that needs to be corrected, which is exactly what Linus was saying. I think Linus was trying to say it in a way that Kent could actually _hear_. It was sad that it had to come at the threat of removal, but Linus has tried multiple different ways, perhaps he just hasn't hit the one that will truly get through to Kent.

                    Just because you are smart or developmentally talented doesn't mean you don't have issues with listening or communicating. This appears to be the case here. I think we all can agree that the best possible result would be if Kent could get the message and change is behavior accordingly. OTOH, what mdedetrich has brought up is essentially correct, there are two speeds of development between new features/experimental code and stable/existing code - Linus probably needs to listen a little more here and be at least open to addressing these issues in the kernel release process. I mean, what does the experimental flag mean, anyway? As long as it doesn't break the build for everone else...

                    Comment


                    • If only bcachefs was written in rust.. we wouldn't have all this drama...

                      Comment

                      Working...
                      X