The Performance Of EXT4 Then & Now

[phoronix]

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

[kingN0thing]

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.

[frantaylor]

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.

[kingN0thing]

another thing that I remember from earlier linux days:

ext2/3 were mostly CPU-bound which means you can increase performance vastly by adding more CPU power. Other file-systems (ie. ReiserFS) are IO-bound which means that you can vastly improve performance by adding a faster disk.

The test platform (Atom 330) might thus be inherently 'unfair' for ext2/3/4. And do not forget that advantages in CPU speed are a magnitude higher than advantages in storage technology.

[deanjo]

The test platform (Atom 330) might thus be inherently 'unfair' for ext2/3/4. And do not forget that advantages in CPU speed are a magnitude higher than advantages in storage technology.

With the number of netbooks/nettops being sold out there I wouldn't call it 'unfair'. Especially since small, weak systems are often used as a "poster child" for linux.

As a side note, "drastic regressions" like these did not occur in openSUSE where ext3 was using barriers enabled by default. AFIK it was the only distro doing so and probably would show a better comparison.

[kingN0thing]

With the number of netbooks/nettops being sold out there I wouldn't call it 'unfair'. Especially since small, weak systems are often used as a "poster child" for linux.

Then call it a performance for Linux Netbook filesystems.. if it is still CPU bound you cannot use this test for a general statement about ext4 performance (ie. what users would expect under a title of "The Performance of EXT4 Then & Now").

[garytr24]

another thing that I remember from earlier linux days:

ext2/3 were mostly CPU-bound which means you can increase performance vastly by adding more CPU power. Other file-systems (ie. ReiserFS) are IO-bound which means that you can vastly improve performance by adding a faster disk.

The test platform (Atom 330) might thus be inherently 'unfair' for ext2/3/4. And do not forget that advantages in CPU speed are a magnitude higher than advantages in storage technology.

I think atom 330 is plenty fast enough for this. I have one as a server, and I can get over 40MB/s through samba file transfers with one of the cores pegged at 100%. But it's dual core with hyperthreading. These benchmarks should be designed to be I/O bound, right?

[kingN0thing]

These benchmarks should be designed to be I/O bound, right?

maybe I was unclear.

Ext2/3 hat the behaviour that it's performance increase was mostly IO bound, reiserfs was mostly CPU-bound.

That means:

base system, both have a performance of 100.

base system with better CPU:
reiser-fs gets 110% I/O performance.
ext3 gets 130% I/O performance.

base system with better (faster) hard drive:
reiser-fs gets 130% I/O performance
ext3 gets 110% I/O performance.

So you might have better I/O performance when using a desktop-level CPU (instead of a netbook CPU). The reason about this are the different in memory data structures (as well as disk format) and access paths within the different file systems.

EDIT: so if you want to know the filesystem performance you should try to match the CPU speed (and cpu count) to the intended system. This makes those kinda-netbook benchmarks not very useful.

[deanjo]

Then call it a performance for Linux Netbook filesystems.. if it is still CPU bound you cannot use this test for a general statement about ext4 performance (ie. what users would expect under a title of "The Performance of EXT4 Then & Now").

CPU or IO bound it's still a valid comparison. Ext 4 has become default on most mainstream distros now. If there is ANY delta difference then the tests are clearly valid as no matter of the reason it is still something that the end user will experience. If everybody ran cutting edge systems then you might have a point calling it unfair on running it on a lower end system but this simply is not the case in the real world.

[kingN0thing]

CPU or IO bound it's still a valid comparison. Ext 4 has become default on most mainstream distros now. If there is ANY delta difference then the tests are clearly valid as no matter of the reason it is still something that the end user will experience. If everybody ran cutting edge systems then you might have a point calling it unfair on running it on a lower end system but this simply is not the case in the real world.

I wouldn't call every non-Atom system 'cutting edge'. And it's not about the speed, it's about the cpu Architecture (and I would think the core architecture more in use than the Atom one) and the ratio between CPU/IO. So a huge delta on a nettop might just not exist on a two-year old desktop PC (the barrier changes will still impose their performance tradeoff, but hey.. if you prefer fast over secure just keep your data in a tmpfs and suspend instead of reboot).

This usecase might be just not representative for desktop computers. Fine for me, but then the OP should title this benchmark in an other way. Well as long as people think about the usability of this benchmark for their file system choosing situation my point has been made.