Benchmarking XFS, ext2, ReiserFS, FAT32

blakestah writes: "Well, it looks like someone on the LKML has taken upon himself to do some benchmarking of ReiserFS, ext2, and XFS using the 2.4 kernel series. It is not a real benchmark test, but kind of interesting nonetheless. See the results (in Spanish) at this LUG in Mallorca. Simple runs of dd, tar, and rm are shown, and for most of the tests XFS is pretty dern fast, beating all the others. The exception is removal of a large source tree (the kernel source), for which XFS is the slowest by a fair amount. See this kernel post for the translations of important words. It will be nice to see more such open benchmarking posted, because benchmarks provide developers goals." The contrast between FAT32 and XFS is particularly interesting to see.

Comments

I've always been pulling for XFS.

[Omega]

I guess I've always been partial to XFS and I hope that it becomes the new default filesystem for Linux.

This guy Dave (I forget his last name now), from sgi gave a presentation to the DC-LUG back in 1999 and talked about XFS and how sgi wanted to release it as GPL to become a core component of Linux. He also talked about the history of XFS and how they had to invent a new size prefix to describe how large a filesystem XFS could accomodate ("exo-byte" = 1024 Gb). XFS has been used by sgi for their MIPS and Cray machines ever since 1984, and now that sgi has donated it to the Linux community, I think we'd be remiss if we didn't welcome it with open arms.

But that's just MHO. ;)

Re:I've always been pulling for XFS.

[enrico_suave]

"I believe 1024 TB is a petabyte. 1024 PB is an exobyte, and 1024 EB os a yottabyte."

Actually I believe 1024 EB is a lottabyte (*badoom tch!*) =P

e.

Re:I've always been pulling for XFS.

[foobar104]

While I agree with the substance of your message, you've got a couple of facts wrong.

First, the maximum filesystem size that XFS can handle is 18 exabytes. Since exabyte is also the name of a brand of tape drive, it's more common to hear of people talking of 18 million terabytes.

(Aside: an intresting statistic found on this page says that as of 1995, 5 million terabytes was about enough data to store all words ever spoken by humans, ever. Cool.)

Also, XFS was never used on Cray systems. XFS made its first appearance (if I remember correctly) on IRIX 5.3 back in 1994. Other than being off by four orders of magnitude in your sizing and by ten years in your dates, I think you're exactly right. ;-)

Either the site's slashdotted already...

[jd]

Or they've a serious PostgreSQL bug. :)

Seriously, XFS looks interesting. I did some stats on source size, and posted them to K5. :) Dropped in score so rapidly, it'll reach the Earth's core sometime in the next half hour.

Essentially, XFS is 10% of the entire kernel size, making it perhaps the single-most sophisticated driver available. On the flip-side, I can't help but feel that that much code is going to have -some- impact on the rest of the system.

Talking of benchmarking, how does IBM's "Next Generation PThread" code stand up? And how on Earth are you supposed to install it? It clashes with glibc, making an RPM install, ummm, of questionable safety. And once you start with RPM (or tarballs, or any other system), it's unwise to mix-and-match. Either you keep track of where things are, or the system does. Half-and-half is NOT good.

Lastly, anyone found a way to get XFS, JFS and AFS into the same kernel? (Without using a sledgehammer, preferbly.)

I managed to get a copy of the page

[Kiwi]

Since I know a little Spanish, here is my very crude translation of the core benchmarks:

First benchmark:

Writing, reading, and deleting a fairly large file (256MB). The commands used are as follows (omitting the redundant 'time' command used in all cases):

• dd if=/dev/zero of=./prova bs=1M count=256
• dd if=./prova of=/dev/null bs=1M count=256
• rm -f ./prova

And the time these commands took (in seconds):

Filesystem Write Read Delete
ReiserFS 18.5 23.41 0.4
Ext2FS 20.3 21.38 0.57
XFS 16.32 19.42 0.26
FAT32 43.65 27.98 1.59 Second benchmark: This benchhmark was donw with the source code of Linux 2.4.4. The .tar.gz file was first uncompressed, so that all the work was done on the tar file (which is larger then 100MB). The commands used on the uncompressed .tar file are as follows (with the time command ommitted again):

• cp linux-2.4.4.tar prova.tar
• tar xf prova.tar
• rm -f prova.tar
• rm -rf linux

The times these commands took (in seconds):

FS Copy Extract rm file.tar rm -rf dir
Reiser 38.48 58.44 0.45 10.09
Ext2FS 21.31 59.19 2.88 11.12
XFS 16.21 35.44 0.18 21.96
Fat32 39.76 134.19 1.2 6.7

XFS size

[Booker]

I can't help but feel that that much code is going to have -some- impact on the rest of the system.

Although XFS is big, it doesn't stomp on the kernel that much.

If you're looking at it from a pure "volume of code" point of view, here's some info:

The XFS patches are split into 2 parts, one which contains kernel changes, and one which is the filesystem itself.

The "core-kernel" patch is about 190k, while the actual filesystem code patch is about 4.3M.

Bear in mind that a 190k patch to the kernel does not mean 190k of new code, either, since you have to take out the context lines, the headers, and the delete lines.

Overall, the impact on the kernel isn't as big as you might think, looking at the overall size.

Now, whether or not executing code in the filesystem slows down the rest of the system, I don't have any real data on that, although I have not noticed any detrimental effect on my system.

XFS deletion performance.

[be-fan]

Yes, XFS does kick that much ass. Still, the deletion performance surprises me. Of course, the other speed things make up for it, but its still a puzzle. If you don't know, rm -rf has historically been a slow operation on XFS.

Here's my theory. Ext2 uses a bitmap to track free blocks, and I'm pretty sure ReiserFS does as well. Free block runs on XFS is managed by two B+trees, one keyed by address, one keyed by size. Thus, allocating space is very fast on XFS, and it is easy to keep things contiguous. However, inserting runs of blocks into both trees is a slower operation then simply clearing the appropriate bits. This would explain the difference between the file creation speed (extraction test) and file deletion speed (rm -rf test.) If this is the case, I think it is quite a good tradeoff, given that space is allocated much more often.

Of course, IANAXE (I am not an XFS engineer) so this is just my theory. I'd appreciate it is someone more informed about XFS could tell me the reason for the performance delta.