Linux 2.6.30 Kernel Benchmarks

[Kano]

If you use Kanotix you can use 2.6.30 + fglrx. As a kernel patch is required it is very unlikely that other distro kernels would work.

[nkef]

These test should be done with 64bit too. On gentoo, we found 2.6.30 over 600% faster in most intensive I/O load (like decompression). A 3 years old (introduced in 2.6.16) regression have been fixed.

This nasty bug makes my Ubuntu 9.04 x64 unusable during intensive I/O load.
Is there any patch for ATI catalyst 9.5 to make it compatible with 2.6.30?

[val-gaav]

Actually I remember Sidux dev saying that from his experience ext4 will be fully stable and proven 3 kernels away from it's introduction as stable into the kernel...

Ext4 was introduced as stable in 2.6.28 so in 2.6.31 it should be all good ...

That being said I'm using ext4 in my jaunty box (2.6.28) and no data loss for me, though when I copy files from some pendrives it's ridiculous slow... Didn't have that problem with ext3 or raiserfs.

[ebird]

I mean data loses for no obvious reason, not because of crash.
Recently I reformatted my old reiserfs storage disks to xfs and I'm very satisfied. Very fast!

I have heard of some data losses with ext4, while it was developed. It will take another year, till this file system is really stable.

The data loses with at splashdot and co, where cause by delayed allocation after a crash. There are test cases at launchpad like this.

1. edit a.new
2. mv a.new a
3. turn off the computer while it is running

=> file a is a 0 byte file

[Apopas]

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.

I mean data loses for no obvious reason, not because of crash.
Recently I reformatted my old reiserfs storage disks to xfs and I'm very satisfied. Very fast!

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

[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).

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

[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'.

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