Benchmarking bogus code
These benchmarks are tough to process by themselves. The older benchmarks are really invalid because the code has a fatal flaw: no data safety. You can make ANY filesystem look fast if you are only pretending to write the data to disk. You might as well benchmark the write performance of /dev/null.
Comparing to other filesystems would be much more interesting.
Every filesystem has the problem of committing data to disk. What is interesting is how they handle it.
-
Are you really complaining that kernel developers have chosen safe over fast defaults?
I dunno, but I <3 my data and would rather prefer that I can access it even if some unlucky power-out happened on my laptop.
If you don't mind that, change the mount option.. that's what it's here for. But the defaults are sane, you can't expect a newbie user to manually alter that kind of thing.Leave a comment:
-
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.
Leave a comment: