Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian [LWN.net]

Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian

Posted May 6, 2006 13:30 UTC (Sat) by anton (subscriber, #25547)
In reply to: Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian by erich
Parent article: Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration)

Metadata integrity buys you fsck time. Thats what it is about, not having to fsck your terabytes (whatever) after a crash.

I don't think that fsck could do anything for data integrity, so that sounds like nonsense. Also, with journaling, fsck time is much less important.

With conventional and journaling file systems, metadata-only integrity is a way to achieve better performance and/or lower complexity.

Ext3 and I guess reiserfs are usually not using full data journalling either, because that is much slower. ext3 can, but I think it comes with a serious speed penalty.

And last time I looked, full data journaling was discouraged for ext3 (apparently that part was no longer maintained).

If an application needs to ensure data integrity, it should be handled in the application, not the filesystem. The application can usually do this much more efficiently. Or at all.

What does data journalling buy you, if you need to be able to handle application crashes and such anyway, too?

What happens on an application crash is completely different from what happens on an system crash (power outage, OS crash etc). You can write an application such that it will not lose data on an application crash, but it can still lose data in case of a system crash (e.g., if the programmer forgot some fsync()s). And resilience against application crashes can be tested much better than resilience against system crashes.

So what I would like to see is a file system with in-order semantics, i.e., where there is no difference between what happens on an application crash and what happens on a system crash. And with the right file system, providing this can be more efficient than littering the applications with fsync()s.

(Log in to post comments)