Announcement

Collapse
No announcement yet.

The Performance Of EXT4 Then & Now

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

  • phoronix
    started a topic The Performance Of EXT4 Then & Now

    The Performance Of EXT4 Then & Now

    Phoronix: The Performance Of EXT4 Then & Now

    Over the past week there has been a lot of talk about the EXT4 file-system following the announcement that Google is migrating their EXT2 file-systems to EXT4. Their reasons for this transition to EXT4 are attributed to the easy migration process and Google engineers are pleased with this file-system's performance. However, as we mentioned in that news post last week and in many other articles over the past weeks and months, EXT4 is not as great of a contender as it was in the past, well, for some tests at least. The performance of the EXT4 file-system commonly goes down with new kernel releases and not up, as kernel developers continue to introduce new safeguards to address potential data loss problems that initially plagued some EXT4 users. For our latest EXT4 benchmarks we have numbers that show this file-system's performance using a vanilla 2.6.28 kernel (when EXT4 was marked as stable) and then every major kernel release up through the latest Linux 2.6.33 release candidate.

    http://www.phoronix.com/vr.php?view=14516

  • fxfuji
    replied
    Methodology ?

    Something is rather odd about the 2 GB IOZone results... for the latest kernels, the write throughput is nearly 2x the read throughput?

    In what world do you live in that hard disks can write data so much faster than they can read it? I'm wondering if there's something wrong with the methodology or measurement, perhaps related to ext4 supporting delayed writes?

    I think it's important not just to do and publish benchmark results, but also to investigate and understand when the results don't pass the 'common-sense test.' Otherwise, the benchmark numbers are no more useful than a random set of digits.

    Leave a comment:


  • Apopas
    replied
    Done! It is bug 223638.
    I'm posting it here in case someone else cares for it as well...

    Leave a comment:


  • deanjo
    replied
    Originally posted by Apopas View Post
    With XFS at least, seems to be normal.
    If I submit it as a bug to KDE, are you gonna to confirm it?
    Sure I will, just pm me the link to it.

    Leave a comment:


  • Apopas
    replied
    With XFS at least, seems to be normal.
    If I submit it as a bug to KDE, are you gonna to confirm it?

    Leave a comment:


  • deanjo
    replied
    Originally posted by Apopas View Post
    Hmmm any possibility to be KDE's bug?
    I would almost lean towards that as to who's bug it is. I don't think I've ever truthfully seen a true accurate progress meter though on high speed transfers on any OS or desktop though.

    Leave a comment:


  • Apopas
    replied
    Hmmm any possibility to be KDE's bug?

    Leave a comment:


  • deanjo
    replied
    Originally posted by Apopas View Post
    So I suppose there is not practical reason for such behaviour and since other filesystems acts correctly, I guess it's a minor bug that should be fixed, right?
    I suppose, I just learned to live with it as one of those things you get used too since the true actual writing performance doesn't seem to suffer.

    Leave a comment:


  • Apopas
    replied
    So I suppose there is not practical reason for such behaviour and since other filesystems acts correctly, I guess it's a minor bug that should be fixed, right?

    Leave a comment:


  • deanjo
    replied
    Originally posted by Apopas View Post
    I see. That means if for some reason RAM is full or there is not enough of it, it delays the copy?
    No it seems more like the initial speed reported is actually dumping to ram then once that is full and the transfer is slower the "meter" then over compensates and reduces the reported speed. Maybe doing it over a network just exaggerates the result even more as initial speeds are well above network capacity.

    Leave a comment:

Working...
X