Btrfs Did Regress Hard In The Linux 2.6.35 Kernel

[kernelOfTruth]

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

[kraftman]

++

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.

[stan]

It seems you're talking bull:

http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.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.

[Chad Page]

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

[yogi_berra]

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.

[DavidNielsen]

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.

[kraftman]

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. :>

[kraftman]

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.