If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

The Performance Of EXT4 Then & Now

01-19-2010, 07:20 AM

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.

Comment

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.

Comment

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.

Comment

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.

Comment

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

Comment

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?

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.

Comment

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.

Comment

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.