Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Data Storage Software Linux

Journalling File System Comparison 38

Posted by timothy from the which-does-what-how-fast dept.
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."
This discussion has been archived. No new comments can be posted.

Journalling File System Comparison More

Journalling File System Comparison

Comments Filter:

  • Possible Explanation for Bad Dir Numbers? (Score:4, Interesting)

    by man1ed ( 659888 ) on Monday May 10, 2004 @10:16PM (#9113159) Homepage Journal
    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.
    • I'll have to agree there. I was gung-ho on using reiserfs, until my filesystem trashed. Then I ran the recovery tool, and it went from a bit trashed to a lot trashed.
      Nothing aginst the reiserfs code itself, as the original corruption could have happened with ext3 also, but the fsck for ext2/ext3 has been around for eons longer, and therefore is much better at recovering from problems.
    • Exactly. What I've seen from all the colored bars is that there are no extreme differences for most usage patterns between the filesystems. ext3 seemed surprisingly slow in some (regular) tests, but otherwise all the journaling filesystems seemed rather evenly matched.

      I wouldn't recommend choosing a filesystem based on this benchmark because it showed that the speed is basically the same within ~20%.

      Is there a benchmark that shows some real difference between these filesystems? Like how they recover from

    • Re: (Score:3, Insightful)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion

  • How about a little consistency... (Score:4, Insightful)

    by llefler ( 184847 ) on Monday May 10, 2004 @10:24PM (#9113225)
    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.

  • Reiser4, and why Ext2 is there (Score:5, Insightful)

    by MBCook ( 132727 ) <foobarsoft@foobarsoft.com> on Monday May 10, 2004 @10:25PM (#9113228) Homepage
    I've seen these kind of things before, but what I'd really like to see is Reiser 4. While I know it's not released yet, you can download the beta and I'd like to see how it performs compared to other filesystems.

    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.

    • Why in the hell would you use ext2 for a RAM filesystem? What's wrong with shm?
      • Just because you have the space doesn't mean it is organized. The filesystems are a way of organizing and managing the data into the neat file and directory paradigm you are used to.

        As far as RAM disk versus SHM, there are occasions where you would like to copy files and store shared files in RAM, especially on systems with plenty of it to spare and busy hard drives.
    • 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.

      Also, because ext2 was used for so long and is not cha

    • 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.

      Even faster and more memory efficient is something like ramfs or tmpfs, which store the data in the cache directly, avoiding filesystem issues entirely (also, if they're not full, the leftover ram can be used for programs!). They won't work for an initrd, but you can copy from an initrd to ramfs, then

    • ext2 is often very fast because it lacks all the journaling stuff which is unimportant for a temporary filesystem.

      It is important to remember that journaling can SPEED performance, not slow it down in many situations.

      The key question is: are you maxing out the drive's IO/bandwidth. On RAID 5 with multiple concurant writes (usually more than 3) you will often see a performance boost for journaling.

      Of course, the real win is when your journal isn't a disk at all, but NVRAM. In that case (e.g. NetApp), you

  • It'd be cool (Score:5, Insightful)

    by dtfinch ( 661405 ) * on Monday May 10, 2004 @10:33PM (#9113268) Journal
    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.

  • ext3 (Score:2, Interesting)

    by Anonymous Coward
    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.

  • Nice (Score:5, Informative)

    by KewlPC ( 245768 ) on Tuesday May 11, 2004 @12:04AM (#9113843) Homepage Journal
    I'd like to see the results of the same test run with a 2.6 kernel.

    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 /tmp.

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

  • FS corruption (Score:5, Insightful)

    by ReyTFox ( 676839 ) on Tuesday May 11, 2004 @01:03AM (#9114103)
    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?

    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 :P
    • Despite having a bad experience with XFS, it's what I use.

      Now, with that said, XFS can be too good.

      Case in point: I accidentally rm'ed most of my homedir. Under most file systems, files are unlinked, yet the data remains, so dumping a raw image or forcing the file system to relink the file is possible; but XFS zeroes out after unlinking.

      Otherwise, I swear by XFS. I might try Reiser4 (once it goes stable) as a root partition, though.

    • Re:FS corruption (Score:3, Insightful)

      by Phouk ( 118940 )

      [...] 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!!! [...]

      As ext2/ext3 are probably much much more widely used than ReiserFS, if there are the same absolute number of problems reported with both, that would of course speak strongly against Rei

  • 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.
    • That's just because you are taking the wrong approach on how to repartition. I've repartitioned/newfs'd a couple of gentoo based systems without having to reinstall or recompile anything. As long as you've got some disk space to spare, it's a reasonably easy process. Boot the livecd, move all the data out from one fs into some other fs temporarily (doesn't have to be a new/empty fs, just so there's room somewhere), create a new fs in the old area, move the data back. Mount /. Update fstab. Reboot.

      Clearly d
  • I'm interested in comparing them with NTFS, anyone?
    • The current state of Linux NTFS support would not allow many of these tests to be run.
    • that would be really good to see NT and NTFS benchmarked

      the NT kernel beating linux would make some people take notice

      regards

      John Jones
    • Comparisons of filesytem are only meaningful with the same hardware, benchmarks, and kernel, so it's currently impossible.

  • Problem with ext3 (Score:5, Interesting)

    by kompiluj ( 677438 ) on Tuesday May 11, 2004 @04:37AM (#9114780)
    In fact you have not one but three ext3's: data=journal, data=writeback, data=ordered (look here [ibm.com] for details) with different performance [namesys.com].
    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 [io.com] 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.
    • Good point. All the other journaled file systems tested run the equivalent of data=writeback, which only journals metadata. By default ext3 journals more data that the others, so it's going to be slower.
  • should have used bonnie++ [coker.com.au] to help benchmark....

  • Ok, this thread is duplicated [slashdot.org] but think of my pleasure to both post and moderate in the same virtual thread!

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close