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

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

Posted Apr 26, 2006 11:53 UTC (Wed) by forthy (guest, #1525)
In reply to: Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian by ikm
Parent article: Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration)

> So what? This is a documented behaviour. Only the metadata is
> preserved, the actual data may be lost.

From a user's point of view, this is not acceptable. And this is neither
true for ext3 nor for ReiserFS, which can keep both data and metadata
consistent.

Just take off your filesystem developer's hat, and take the user's hat
on: What's a file worth that sits there, has the correct name, the
correct length, the correct date, no warning sign, and just garbage in?
Nothing! It's worse than having that file deleted, because if it's
deleted, you know it's gone. If it's just tampered, and you don't know it
is, you are toast.

So stay away from filesystems that promise you just "metadata integrity",
because it buys you nothing. Either go full way (data+metadata journaling
or at least ordering), or no way (completely fscking random rubbish in
case of a crash, because then you at least know that it's completely
fscking random rubbish, and you have to dig out your backup).

(Log in to post comments)

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

Posted Apr 26, 2006 13:02 UTC (Wed) by ikm (subscriber, #493) [Link]

> From a user's point of view, this is not acceptable.

Sure, I actually agree. Just that it's not a bug, but a documented behaviour. OTOH, it should say it more clearly, and the fs itself should not be PRed as a powerfail-safe solution.

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

Posted Apr 27, 2006 13:16 UTC (Thu) by erich (subscriber, #7127) [Link]

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

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.

Just get a log of your fsck on reboot, and you should have information on which files were trashed, and restore them from backup if they aren't okay.

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.

A database file will be changing all the time, probably only being in a completely "consistent" state only when the database server is actually shut down properly. What does data journalling buy you, if you need to be able to handle application crashes and such anyway, too?

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

Posted May 6, 2006 13:30 UTC (Sat) by anton (subscriber, #25547) [Link]

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.