Announcement

Collapse
No announcement yet.

EXT4 & Btrfs Regressions In Linux 2.6.36

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

  • EXT4 & Btrfs Regressions In Linux 2.6.36

    Phoronix: EXT4 & Btrfs Regressions In Linux 2.6.36

    Recently when benchmarking the Btrfs and EXT4 file-systems we were left surprised that the performance of the next-generation Btrfs file-system had regressed against EXT4 to the point where the evolutionary file-system is measurably faster in a greater number of disk benchmarks. In fact, even with solid-state drives and Btrfs offering an SSD optimized mode, it still conceded to EXT4. It turns out that in the Linux 2.6.35 kernel, Btrfs regressed. This regression should have been fixed with the Linux 2.6.36 kernel, but recently when benchmarking EXT4/Btrfs against ZFS-FUSE on a 2.6.36 development snapshot we found its performance to still be poor for Btrfs compared to EXT4. To confirm where these two most prominent Linux file-systems are at right now, we have new EXT4 and Btrfs performance results from the Linux 2.6.34, 2.6.35, and 2.6.36-rc3 kernels.

    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
    Without some sandbox for all the developers of all the various systems to play together in without having to worry about breaking things, how is anybody to know how things will work when everybody gets together all at once to merge in their possibly massive and incompatible changes within the tiny allowed timeframe (only to be disallowed from making the possibly sweeping changes necessary in order to fix things properly)? This sounds like a terrible development model. And why is it called a release candidate? There is absolutely zero chance that -rc1 is bug free and will be released as-is, and thus, not a candidate for release. It's that simple.

    I need to finish school and learn C so I can help fix this shit. Totally ridiculous. The world needs more CK's. It also sounds like we need a way to make big changes which break things and then have the ability to eventually get those changes mainline only after everything gets integrated properly. Evolutionary change sometimes sucks and causes big ugly codebase.

    Comment


    • #3
      Something just causes high CPU load. Nothing spectacular. They'll find it. It has happened again.

      Comment


      • #4
        Originally posted by Smorg View Post
        [...]
        I don't know where you have see that release candidate equal bug-free release. Such aren't normalized in any way so I guess Linus can name his prerelease as he wants. Also it's no because you think that the rc1 is the first release of code that no testing was done before.

        Your whole post prove that you have nearly no understanding , if absolutely none, on how the kernel is structured and organized. You will have to learn a little bit more than C before you can "fix this shit".

        Comment


        • #5
          Originally posted by Smorg View Post
          Without some sandbox for all the developers of all the various systems to play together in without having to worry about breaking things, how is anybody to know how things will work when everybody gets together all at once to merge in their possibly massive and incompatible changes within the tiny allowed timeframe (only to be disallowed from making the possibly sweeping changes necessary in order to fix things properly)? This sounds like a terrible development model. And why is it called a release candidate? There is absolutely zero chance that -rc1 is bug free and will be released as-is, and thus, not a candidate for release. It's that simple.

          I need to finish school and learn C so I can help fix this shit. Totally ridiculous. The world needs more CK's. It also sounds like we need a way to make big changes which break things and then have the ability to eventually get those changes mainline only after everything gets integrated properly. Evolutionary change sometimes sucks and causes big ugly codebase.
          Just in-case any other lurker is reading this thread I'd like to point out that the quoted message is pure FUD and may be a troll-post.

          Comment


          • #6
            Originally posted by Smorg View Post
            I need to finish school and learn C so I can help fix this shit. Totally ridiculous. The world needs more CK's. It also sounds like we need a way to make big changes which break things and then have the ability to eventually get those changes mainline only after everything gets integrated properly. Evolutionary change sometimes sucks and causes big ugly codebase.
            That's actually being done already. There's a world of its own happening behind Linus' git tree which these release candidates and releases are tagged from. But feel free to participate, I doubt anyone complains about extra testing for code before it ends up in Linus' tree.

            Comment


            • #7
              Originally posted by Smorg View Post
              Without some sandbox for all the developers of all the various systems to play together in without having to worry about breaking things, how is anybody to know how things will work when everybody gets together all at once to merge in their possibly massive and incompatible changes within the tiny allowed timeframe (only to be disallowed from making the possibly sweeping changes necessary in order to fix things properly)? This sounds like a terrible development model. And why is it called a release candidate? There is absolutely zero chance that -rc1 is bug free and will be released as-is, and thus, not a candidate for release. It's that simple.

              I need to finish school and learn C so I can help fix this shit. Totally ridiculous. The world needs more CK's. It also sounds like we need a way to make big changes which break things and then have the ability to eventually get those changes mainline only after everything gets integrated properly. Evolutionary change sometimes sucks and causes big ugly codebase.
              Stuff that gets merged is a bit more tested than "Hey Linus, I rewrote the TCP stack over the weekend after having a few too many beers on Friday. Mind if this gets merged for the next release?"

              Anything getting merged into Linus's branch should have been pretty thoroughly tested before hand.

              Comment


              • #8
                oi....I realize that this is just a "this is what we noticed with our benchmark suite post" so there isn't a lot of depth on what vfs, block, or scheduling changes might have had an effect, but it really brings out the Smorgs of the word who have a vastly simplified view of how things work.

                I realize you don't want to do 2 weeks of analysis and then post a full write up as you'd rather post something now, but it'd be nice to at least include a little bit of something. Maybe a few select commits or merges that had an effect on the benchmark? I know some of the VFS scalability stuff went into 2.6.36, which in the short term might hurt performance on single threaded workloads.

                Comment


                • #9
                  On the factual side:

                  So this happens with SSDs but not HDDs? You spend an article showing us how 2.6.36 is slower, then you tell us that you can't reproduce the results on another system. That certainly makes things more complicated, but at this point it would probably make sense for the community to run the same tests and see if we get the same results, then cross-reference that result with whether each person has an HDD or an SSD. Maybe this regression is only noticeable on SSDs for some reason (because they have such a fast access time, for instance?)

                  On the insane/troll/etc side:

                  <Cue comment about Oracle intentionally trying to sabotage btrfs to make people switch to Solaris>

                  Comment


                  • #10
                    Has the slow I/O issue with .35 btrfs been resolved yet?

                    Comment

                    Working...
                    X