Announcement

Collapse
No announcement yet.

Btrfs Did Regress Hard In The Linux 2.6.35 Kernel

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

  • #11
    Originally posted by kraftman View Post
    I'm sorry, but I don't understand you. Why 2.6 series aren't stable in your opinion? I wouldn't even touch 2.4 series.
    ++

    this

    take a look at lkml.org

    there are a whole bunch of stable kernels available

    mainline 2.6.35 patch log
    stable 2.6.35 patch log
    stable 2.6.34.2 patch log
    stable 2.6.33.7 patch log
    stable 2.6.32.17 patch log
    stable 2.6.31.14 patch log
    stable 2.6.27.49 patch log
    2.4 kernels aren't even mentioned

    Comment


    • #12
      Originally posted by kernelOfTruth View Post
      ++

      this

      take a look at lkml.org

      there are a whole bunch of stable kernels available



      2.4 kernels aren't even mentioned
      Haha, yes. I was just according to Greg KH talk.

      Comment


      • #13
        Originally posted by kraftman View Post
        It seems you're talking bull:

        http://git.kernel.org/?p=linux/kerne...git;a=shortlog

        Could you point to zfs and solaris mailing list to have some comparison?
        Kind of telling that BTRFS had only 3 commits in July whereas in April it got over 100+.

        As for a comparison zfs mailing list, see here.

        Comment


        • #14
          Oracle+Sun: Where even more open source goes to die. (?)

          Comment


          • #15
            Originally posted by kraftman View Post
            I'm sorry, but I don't understand you. Why 2.6 series aren't stable in your opinion? I wouldn't even touch 2.4 series.
            It's the development model, i.e. porting features from a development branch into a branch.

            Now everyone is a beta tester.

            Comment


            • #16
              This seems like a good time to update the test suite with a test case for this.

              The everyone is complaining that the test suite is flawed since it does things like test compression performance test against far to optimal data.

              So let's fix it, let's focus on where we want to go rather than how to get there. What kind of regression are interesting, how do we confirm they are statistically valid, and consistent?

              How do we justify changes that might regress certain performance cases in favor of fixing suboptimal behavior such as the Lumpy Reclaim patches?

              Let's figure out how to make the benchmarks valid and useful to the wider community. We can start with this one and work our way up.

              Comment


              • #17
                Originally posted by stan View Post
                Kind of telling that BTRFS had only 3 commits in July whereas in April it got over 100+.

                As for a comparison zfs mailing list, see here.
                Thanks. However, it's a zfs-discuss list, so it's hard to see what's a commit and what's not. While btrfs get over 100 commits in April then it seems everything is fine. There are also many commits in May too. Btw. we've got holidays, so this probably has some influence. :>

                Comment


                • #18
                  Originally posted by yogi_berra View Post
                  It's the development model, i.e. porting features from a development branch into a branch.

                  Now everyone is a beta tester.
                  You're probably right. In my opinion distros should test and choose optimal kernel and kernel which is stable, which doesn't have regressions (if it has, then they should report this and try to fix before the final release of distribution) etc. I see kernel.org like a bazar, you take what fits you best. You can even take some interesting parts only and backport them to the previous kernel, you can disable not so well tested features etc. Debian will take older kernel, Ubuntu some newer one and Fedora the newest. Those are distros which should decide what to take and how to use it.

                  Comment

                  Working...
                  X