Linux 2.6.30 Kernel Benchmarks

[ebird]

It is really something wrong with all the kernels > 2.6.20. I get results with the threaded io write test with 64MB and 32 threads about 500ms with 2.6.20 kernel. While the kernel 2.6.29 kernels returns times about 2.500ms on my machine. I have remove the smp support on my Core2 Duo @ 2.4GHz to minimize scheduler differences. Both kernels are vanila kernels.

[deanjo]

With the Linux 2.6.28, 2.6.29, and 2.6.30-rc7 kernels we obtained the x86_64 vanilla kernels from the Ubuntu mainline kernel PPA.

Well dammit it should have been ran on a FUJITSU VENUS SPARC64 VIIIFX dammit. These results are completely invalid.

[energyman]

AFAIK they changed some default mount options for ext3 - all fs 'improvements' - aka dbench, can be nicely explained by this. Less secure, more 'performance'.

I will stay with reiser4 - the fs that cares about data.

[Yfrwlf]

AFAIK they changed some default mount options for ext3 - all fs 'improvements' - aka dbench, can be nicely explained by this. Less secure, more 'performance'.

I will stay with reiser4 - the fs that cares about data.

Well so does btrfs supposedly. Fortunately, with ext and probably reiser too you can adjust the options to favor data integrity over speed, if you don't like it, AFAIK.

[energyman]

which is stupid. Save should be default. If someone needs speed, he can tweak. Being fast-but-unsecure is nice for benchmarks - and horrbile wrong in real life.

ext3 has barriers off per default - idiotic. And now unsafe options by default - more idiotic. It only shows that extX devs don't care about their users data. Only benchmarks.

[deanjo]

which is stupid. Save should be default. If someone needs speed, he can tweak. Being fast-but-unsecure is nice for benchmarks - and horrbile wrong in real life.

ext3 has barriers off per default - idiotic. And now unsafe options by default - more idiotic. It only shows that extX devs don't care about their users data. Only benchmarks.

AFIK, the only distro that enables barriers by default is opensuse.

[susikala]

Well, these tests were performed using ext3, from today's point of view a rather obsolete file-system. It will most likely completely replaced with ext4 by the next batch of the major distros (doesn't Leonidas already have it as default?).

From the little reading I did I understand ext4's delayed allocation solves the problem of secure vs. fast, or at least mitigates it.

Which basically means, complaining about the changes in ext3 is pointless. Maybe it's exactly _because_ ext4 will soon become default that the developers allow themselves more room in improving an otherwise broken situation (just look at some of the horribly slow benchmarks Linus / Jens Axboe posted). If your data is really important to you, back it up, or tweak the file-system to quasi 'do it for you'.

[energyman]

no, delayed allocations are the big reason, why ext4 sucks. It does the same crap as xfs did - we don't care about your data, we only care about benchmark speed. You lost data? Your own fault.

extX devs don't care about data.

[Apopas]

no, delayed allocations are the big reason, why ext4 sucks. It does the same crap as xfs did - we don't care about your data, we only care about benchmark speed. You lost data? Your own fault.

extX devs don't care about data.

Actually, I' ve heard a lot of times about data loss in ext4 hard drives, but no for xfs (the last years at least).

[ebird]

Actually, I' ve heard a lot of times about data loss in ext4 hard drives, but no for xfs (the last years at least).

That's because kids are playing with not finished file systems. And there are data loses with xfs after an crash. It's the same as ext4.