Slashdot Mirror
Journalling File System Comparison
Ithika writes "Justin Piszcz recently did an analysis of some common journaling file systems over at Linux Gazette. Due to the Gazette's ridiculous restrictions on image filesize all of the graphs are pretty much illegible, however. You can see the article as the author originally intended here."
Regarding the bad performance of ext3 on directories, is this feasible?:
Since every directory has two entries in it ("." and ".."), that is three times the number of directory entry creations/deletions that need to be journaled. Perhaps the other journaling FSs have some optimization for handling "." and "..".
It's important to pick a filesystem that performs the main task asked of a filesystem. Keeping that criteria in mind, it's easier to make sense of these results.
Pick the filesystem that won't trash your data. I haven't seen any benchmarks that show stats like errors in the filesystem code, maturity, or how often the filesystem corrupts unexpectedly.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
One graph has ext2 first, the next has xfs. ext3 is light blue in one, purple in the next. I quickly found that after having to recheck the key for each graph, I really didn't care anymore.
It is amazing what you can accomplish if you do not care who gets the credit. -- Harry Truman
Otherwise, an interesting article.
And for the complainers who say "Why include ext2, everyone should use a journaling filesystem", there are two reasons. First is that ext2 is a MAJOR STANDARD that was what everyone used for years and years. The second is that ext2 is still usefull. For a temporary filesystem (like /tmp or some temporary RAM disk with unimportant contents) ext2 is often very fast because it lacks all the journaling stuff which is unimportant for a temporary filesystem.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
If there was a spreadsheet to go with that. One could normalize the results and weight each benchmark according to their performance needs. And there are differences between the 2.4 and 2.6 kernels' IO handling that could make an fs perform better on one kernel than the other.
But since he's done this all for free, all I can say is thanks.
I must say that ext3 has had major improvements in 2.6 (no, I know that won't help people running 2.4 so you don't need to tell us again).
I'd still use it for any system unless I could demonstrate that it really couldn't handle the workload.
Then again with the hard disk being a bottle neck quite often in desktop systems, there is something to be said about a fast filesystem there.
I'd like to see the results of the same test run with a 2.6 kernel.
/tmp.
Also, people should pick a file system that suits that task at hand:
-XFS was designed for handling large files quickly, and on a file system where most of the files are at least a few megabytes in size, XFS will reign supreme.
-ReserFS, on the other hand, is excellent for file systems with lots and lots of small files.
-ext2 is still useful. For instance, there's no need for journalling in
-ext3, at least under 2.6, is a decent desktop file system. While not the fastest, it's reliable, and its performance in the 2.6 kernels is much better than in the 2.4 kernels. It should be sufficient for most desktop file system needs.
As to file system reliability, from what I've heard, all the major file systems are pretty solid in the 2.6 kernel.
One test that wasn't in the article was a reliability test - i.e. if something bad happens, how much is lost? Or just as importantly, can you guarantee the FS will work as long as the storage device does?
:P
I've noticed that many people seem to have a bias against ReiserFS for being a less stable FS. There is some truth to that, I suppose, since it's newer, but I've poked around google for hard facts, and couldn't really find any evidence from the past 1 to 1-1/2 years of particular problems with *any* of the major filesystems. All I came up with were anecdotes, and not only that: There were just about as many with horror stories about ext2 and ext3 as with Reiser!!!
So I wouldn't worry about corruption unless it's already happened to you; experience is the best teacher
Two days or so (can't even remember when :) ) after I repartion my drives for a new linux install, this in and of itself is not a big deal as I haven't done too much since, so going back a few days isn't too bad...unless my linux distro was gentoo and having no desire to recompile/manually configure everything I think I'm happy for now.
I'm interested in comparing them with NTFS, anyone?
All of the filesystems tested are pretty mature. Reiserfs had some early 2.4 kernel issues (but then again, what didn't!). JFS is the "youngest" of all those (Well, JFS on linux anyway). A filesystem would have to be of pretty shitty design these days to have random corruption issues. You'd be more likely to have hard drive issues before random filesystem corruption issues.
In fact you have not one but three ext3's: data=journal, data=writeback, data=ordered (look here for details) with different performance.
So if anyone tries filesystems comparison, please benchmark all three data modes of ext3 or, at least, provide information which one was used in the test.
To add my 0.02 EUR I would also like to see comparison of linux filesystems against *BSD ufs2 on the same machine. I know that the underlying operating system adds additional variables in the equation, but if you are interested in filesystem-oriented tasks the system's performance as a whole counts, not only its filesystem. I have seen something like this done already for RAIDs but I would like to see this for ordinary single drives (like ATA and SATA). Shall I have enough time I will perform such tests end of July, when my new hardware arrives.
You can defy gravity... for a short time
i never see benchmarks run with some other cpu or disk intensive app running on the machine. some weaknesses in the filesystems may show up with something else running, say a loop of a set of wav files being encoded to mp3's. i know this will add inconsistancies, but i don't expect that the filesystems are consistant about how they are impacted by multiple apps running.
will the a/c
should have used bonnie++ to help benchmark....
Ok, this thread is duplicated but think of my pleasure to both post and moderate in the same virtual thread!
You can defy gravity... for a short time