| |||||||||||||
|
| |||||||||||||
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (DebianFilesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (DebianPosted Apr 26, 2006 10:32 UTC (Wed) by ikm (subscriber, #493)In reply to: Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian by khim Parent article: Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration)
> I was biten by this bug myself quite a few times: system looked "just fine"
So what? This is a documented behaviour. Only the metadata is preserved, the actual data may be lost. This is also true for most of the other journalled filesystems. And XFS here actually has an advantage over many of them: it guarantees that the data that was lost will be filled with zeroes, instead of any garbage, which can leak sensitive information and so on.
(Log in to post comments)
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Posted Apr 26, 2006 11:53 UTC (Wed) by forthy (guest, #1525) [Link] > 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).
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.
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Posted Apr 26, 2006 15:59 UTC (Wed) by khim (subscriber, #9252) [Link] So what? This is a documented behaviour. Only the metadata is preserved, the actual data may be lost.
Then why have logging filesystem at all ? Note: I'm not talking about "fresh" files - they are not expected to survive. But when files created days and weeks ago perish in crash... sorry - this is not what I expect from logging filesystem. In few cases I even had corrupted files which survived first crash but not second one - gosh. Worse then EXT2 without any logging: at least there you can be sure files are there - or not...
|
|
||||||||||||