Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 25

Thread: Linux 2.6.30 Kernel Benchmarks

  1. #11
    Join Date
    Oct 2007
    Location
    Hannover
    Posts
    21

    Default

    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.

  2. #12
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

    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.

  3. #13
    Join Date
    Jul 2008
    Posts
    1,728

    Default

    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.

  4. #14
    Join Date
    Jul 2008
    Posts
    565

    Default

    Quote Originally Posted by energyman View Post
    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.

  5. #15
    Join Date
    Jul 2008
    Posts
    1,728

    Default

    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.

  6. #16
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

    Quote Originally Posted by energyman View Post
    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.

  7. #17
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    258

    Default

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

  8. #18
    Join Date
    Jul 2008
    Posts
    1,728

    Default

    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.

  9. #19
    Join Date
    Mar 2009
    Location
    Hellas
    Posts
    1,099

    Default

    Quote Originally Posted by energyman View Post
    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).

  10. #20
    Join Date
    Oct 2007
    Location
    Hannover
    Posts
    21

    Default

    Quote Originally Posted by Apopas View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •