The Linux 3.0 Kernel With EXT4 & Btrfs

[phoronix]

Phoronix: The Linux 3.0 Kernel With EXT4 & Btrfs

With the Linux 3.0 kernel carrying CleanCache support along with various improvements to the EXT4 and Btrfs file-system modules, it is time for another Phoronix file-system comparison. This time around the EXT4 vs. Btrfs performance is particularly important with Fedora 16 possibly switching to Btrfs by default. Due to this level of interest, for our Linux 3.0 kernel benchmarks of the EXT4 and Btrfs file-systems, an Intel SSD was tested as well as an old 5400RPM IDE notebook hard drive to represent two ends of the spectrum.

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

[flammon]

A few of things.

1. XFS is a quite capable, full featured and still competitive filesystem and it would be nice see how it fares in these benchmarks.
   
2. Which benchmark would be the most pertinent to an app developer or a web server or a database server or a typical office user?
   
3. I would love to see how much multiple cpu cores affect the performance of each filesystem. When it comes to CPU usage, I have plenty and I'm barely using any of it so when there's a tradeoff to be made, the filesystem that maximizes CPU usage for even the slightest gain in IO performance wins in my book. In other words, if increasing the filesystem performance has a heavy cpu cost, then I'm all for it. I have six cores on my desktop and I'd be glad to give one up to the filesystem.

[l8gravely]

[QUOTE=phoronix;215567]Phoronix: The Linux 3.0 Kernel With EXT4 & Btrfs

From looking this over, the key thing I can draw from this comparision is that both filesystems are pretty darn close to each other in terms of performance. The next step would be to compare features and manageability.

I'd love to see some tests where you grow a filesystem, shrink a filesystem, and then crash a filesystem and see how long it takes to FSCK and how much data you lose.

Because I'm all for speed, but I'm more interested in NOT LOSING any of my data due to filesystem corruption issues. Yet I'm also interested in being able to grow/shrink filesystems easily.

Now I realize that coming up with a consistent fsck test could be hard, but maybe you could do something like this:

1. Build a pair of LVM volumes with idential sizes.
2. Create and populate each filesystems with an identical sampling of files/directories.
3. Then corrupt each filesystem with the same identical bit/block error(s).
4. fsck and report the timing and the results.

This would have to be repeated a bunch of times, and I'm not sure how we'd test live crashes where you're writing data to the filesystem and the system reboots forcing an FSCK. Possibly by doing this work all on the same eSATA drive and pulling the cable?

The idea would be to see how resilient each filesystem is. And unfortunately, getting a repeatable, automated test might be hard to do. I'd do some of this but I don't have any eSATA enclosures.

Thanks for all your hard work.
John

[jakubo]

are you sure the performance for the first (or second) test is bottlenecked at the cpu? if it were then different file systems would in fact HAVE differences wouldnt they? id rather think its upon some 12-17 ms latency found on hdds (compared to few ns on sdd)
and like i wrote before, i think there might be some driver issuesomewhere as for my laptop (lenovo n100) (Sata-)hdd the throughput is at half the maximum as given by the vendor... (24MB/s max, while vendor says its capable of up to 60MB/s)

[ssam]

BTRFS has some fancy features. its worth moving to even if it was slower. might wait until it is considered a bit more stable (maybe when fedora make it default).

[hechacker1]

Thanks for benchmarking standard HDDs. Much more relevant than SSDs for the majority of people who still have them.

But I would still like to see a desktop HDD (7200 or 10000 raptor) which have better response times and transfer rates.

The pentium-m is a little bit troubling, because they are so outdated now. My pentium-m system doens't even have a working intel driver anymore (just vesa or fbdev). So considering it isn't getting support, and it could be bottlenecking the file-system algorithms, I think a faster Core 2 would be better.

[drag]

XFS is a quite capable, full featured and still competitive filesystem and it would be nice see how it fares in these benchmarks.

I would like to see XFS comparison. Not because it's full featured and still competitive... which it is certainly not. Not in terms of features. But it's widely used for a variety of reasons.

It makes a nice way to compare these two file systems in a way other then relative.

BTRFS has some fancy features. its worth moving to even if it was slower. might wait until it is considered a bit more stable (maybe when fedora make it default).

It needs a proper fsck utility. That's the hold up right now. Once that is done then I will use it on all my systems other then ones that are important.

[Artemis3]

It needs a proper fsck utility. That's the hold up right now. Once that is done then I will use it on all my systems other then ones that are important.

Same here...

[Uqbar]

Why comparing a Pentium M/HDD with a Sandy Bridge/SSD chip?
Data bus, L2+L3 cache and number of cores (not to talk about clock, RAM speed etc.) make those two chips as different as a bycicle and a Lamborghini.
You could even test a 60 MHz Pentium w/ 32 MB RAM, 200 MB PATA disk or a 80486 w/ 8 MB RAM and a 30 MB disk!
Of course none outperforms the i7!, even with a 32bit 1.2.13 kernel!
You want to make a reasonable Linux 3.0 test?
Define the hardware, install a distribution of your choice, and then just swap the kernels. That's it. Anything else (like you did) sounds just ... kidding!
That test doesn't show anything but the technology gap in the past 10 years: a 4x to a 100x factor.

[jumico]

Why comparing a Pentium M/HDD with a Sandy Bridge/SSD chip?
Data bus, L2+L3 cache and number of cores (not to talk about clock, RAM speed etc.) make those two chips as different as a bycicle and a Lamborghini.
You could even test a 60 MHz Pentium w/ 32 MB RAM, 200 MB PATA disk or a 80486 w/ 8 MB RAM and a 30 MB disk!
Of course none outperforms the i7!, even with a 32bit 1.2.13 kernel!
You want to make a reasonable Linux 3.0 test?
Define the hardware, install a distribution of your choice, and then just swap the kernels. That's it. Anything else (like you did) sounds just ... kidding!
That test doesn't show anything but the technology gap in the past 10 years: a 4x to a 100x factor.

Isn't this test about comparing the filesytems? I don't think they're trying to compare the ssd to the hdd.