EXT3, EXT4, Btrfs Ubuntu Netbook Benchmarks

[pvtcupcakes]

Interesting comparison. I wonder what the upgrade path from ext4 to btrfs will look like: backup, format, restore? A quick search doesn't bring up anything.

What I did was put my entire / into a tarball, put that on a large external hard drive, format, and untar.

If you're kind of limited on storage space, I'd recommend the xz compressed tarball. I compressed my ~35gb filesystem to 13gb.

Have a look at this Gentoo wiki page: http://en.gentoo-wiki.com/wiki/Custom_Stage4

It says to exclude /dev from the tarball, but if you do that, remember to copy /dev/null, /dev/zero, and /dev/tty1 from a LiveCD or whatever. Otherwise udev is going to have some major problems. And use -a option on cp. You might just be better off including /dev.

And you can safely ignore a lot of the article, it's mostly for moving a filesystem to a different machine and not so much backup and restore.

[RussDill]

What I did was put my entire / into a tarball, put that on a large external hard drive, format, and untar.

If you're kind of limited on storage space, I'd recommend the xz compressed tarball. I compressed my ~35gb filesystem to 13gb.

Have a look at this Gentoo wiki page: http://en.gentoo-wiki.com/wiki/Custom_Stage4

It says to exclude /dev from the tarball, but if you do that, remember to copy /dev/null, /dev/zero, and /dev/tty1 from a LiveCD or whatever. Otherwise udev is going to have some major problems. And use -a option on cp. You might just be better off including /dev.

And you can safely ignore a lot of the article, it's mostly for moving a filesystem to a different machine and not so much backup and restore.

Its really too bad more people aren't finding the wiki:

http://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3

# Always run fsck first
fsck.ext3 -f /dev/xxx

# Convert from Ext3/4->Btrfs
btrfs-convert /dev/xxx

# Mount the resulting Btrfs filesystem
mount -t btrfs /dev/xxx /btrfs

[F.Ultra]

The SQLite test is really interesting from a programmers view since it represents the very worst usage case of SQLite. If you have lots of inserts like this you should perform them inside a transaction.

I downloaded and performed the test on my local EXT4 machine with and without transactions:

without (as in the benchmark): 27 inserts per second
with transactions: 24558 inserts per second

Sadly I have no EXT3 partition, it would be interesting to see whether EXT3 would enjoy the very same performance gain since it shows less MBps capability than EXT4 or Btrfs.

Still it is a very good benchmark since it really shows the number of possible transactions per second, but one does wonder if EXT3 really performs true transactions since it has a so much higher number.

[cruiseoveride]

I hope when doing certain tests (like unpacking the kernel) the output is directed to /dev/null because any variations in performance between distros can be attributed to the 2D performance of the graphics drivers.

[etymxris]

Some of the results look really fishy. How are you accounting for files being cached in memory by the kernel? It seems you should do a cold boot with swap disabled before each test, and make sure the files being tested are not accessed in any way before the test is run.

In real life files will be cached, and you want your file system to work effectively with cache. So there should be cached results too, where obviously the data set is larger than the largest possible cache.

[mtippett]

"while Ubuntu 10.04 is using Linux 2.6.32"

For BTRFS it should be nice to test it with its latest code, or at least with 2.6.33-rc8. It's an experimental FS so its important to see its latest improvements. As always phoronix is too ubuntu focus.

Anyway good article, and WOW!! nice BTRFS perfomance!, a compressed btrfs partition results should be interesting to see too!!

Regards

The intent of the benchmarking was to compare the Ubuntu supported filesystems. If Ubuntu was planning to pick up bleeding edge FS code from upstream, then it would have been covered.

The benchmark is intended to allow people to understand the impact of choosing one filesystem over another. It provide quantitative data rather than a qualitative FS A is WAY faster than FS B. You've got the information to make a judgment when you install a karmic or lucd build and are asked to choose your FS. Once installed (at installation time), most people don't change their FS.

[mtippett]

I find these filesystem comparisions interesting, yet I think they lose some value by only including a type of storage. I don't even know if there are differences in the way filesystems work with SSDs and HDDs, so what I would like is some clarification on this matter. Maybe there are some filesystems that are more suited for SDDs and others for HDDs?

Number one rule of comparisons. Change one variable and one variable only. In this case the FS was changed. The next dimension to hit is to change the HDD technology. But which FS do you use for all the tests? Running them all yields too many test passes. These results allow you to go the next dimension after you choose the FS that best supports your workload.

[mtippett]

Timing things like

git fast-import
git add/commit
git checkout <branch>
git gc

With a test repo.

Create a PTS test case and provide it to Michael. I am sure he'll include it. Just make sure it is relevant and measures what you are wanting it to measure. (This means writing a textual paragraph covering what you are actually testing).

[mtippett]

The SQLite test is really interesting from a programmers view since it represents the very worst usage case of SQLite. If you have lots of inserts like this you should perform them inside a transaction.

...

without (as in the benchmark): 27 inserts per second
with transactions: 24558 inserts per second

...

Still it is a very good benchmark since it really shows the number of possible transactions per second, but one does wonder if EXT3 really performs true transactions since it has a so much higher number.

The SQLite test as it stands is *very* sensitive to the fsync/fdatasync. You can tune the test to demonstrate database performance, but it currently isn't intended to do that. The intent of the test is to show the FS performance, and to simulate some contrived situations where people can't do transactions (like a busy 2-tier PHP site. The 3rd tier allows you to aggregate transactions, but a 2-tier won't)..

In most cases where there is a large delta, it has been shown that the "faster" FS has either traded performance for data integrity or have thrown out integrity altogether (there was a KVM/QEMU bug that mean a sync file operation would end up being async. The guest running under KVM was about 100 times faster than the host for the SQLITE test. As it turns out the fsync in the KVM, wasn't really an fsync to the physical disk anyway.

[jhansonxi]

typo

On page 3:

When doubling the write size in IOzone to 8GB, EXT4 and Btrfs continued to operate much faster than EXT4.

I think there's an EXT3 missing somewhere.