Forum Moderators: bakedjake
Kerneltrap has posted benchmarks (for the future version) and some discussion on the topic: Linux: Benchmarking Filesystems In 2.6.0-test2 [kerneltrap.org]
Journalled filesytems have a runtime cost, and you're paying that all the time.If you're going 200 days between crashes on a disk-intensive box then using a journalling fs to save 30 minutes at reboot time just doesn't stack up:
you've lost much, much more time than that across the 200 days.
It all depends on what the machine is doing and what your max downtime requirements are.
I had a powercut last night, ext3 handles that very, very well...
<added>You added to your post as I replied, now I look like I don't have a clue ;) - That's actually mostly true. But, from a Linux Desktop users point of view I do find ext3 to be very reliable and stable. As far as servers go, well, I'll leave that to the more tech minded Linux users....</added>
Nick
If you only have remote access to the box, life may not be pleasant fixing an ext2 filesystem if the box loses power.
Perhaps I am mistaken, however in the past I have had to get in front of the machine, boot into single user mode and fix the filesystem "manually" when I used ext2. Losing power on an ext2 system can also royally screw your database tables.
I haven't had any trouble with performance with ext3, however I honestly haven't paid much attention to it. It makes sense that you pay something of a performance penalty.
Take care,
This is why a journaled system, or even better, UFS with softupdates is preferred. With UFS, you get the benefits of having your metadata always being in a consistent state and short fsck times, without wasting space on a journal.
In FreeBSD 5.x, you even get a background fsck, so your system can come up immediately and fsck in the background while your system is operational.