On Tue, 12 Aug 2003, Andrew Sullivan wrote:
> On Mon, Aug 11, 2003 at 10:58:18PM -0400, Christopher Browne wrote:
> > 1. Nobody has gone through any formal proofs, and there are few
> > systems _anywhere_ that are 100% reliable.
>
> I think the problem is that ext2 is known to be not perfectly crash
> safe. That is, fsck on reboot after a crash can cause, in some
> extreme cases, recently-fscynced data to end up in lost+found/. The
> data may or may not be recoverable from there.
>
> I don't think anyone would object to such a characterisation of ext2.
> It was not designed, ever, for perfect data safety -- it was designed
> as a reasonably good compromise for most cases. _Every_ filesystem
> entails some compromises. This happens to be the one entailed by
> ext2.
>
> For production use with valuable data, for my money (or, more
> precisely, my time when a system panics for no good reason), it is
> always worth the additional speed penalty to use something like
> metadata journalling. Maybe others have more time to spare.
I think the issue here is if you are running with the async mount option,
then it is quite likely that your volume will be corrupted if there are
writes going on and power fails.
I'm pretty sure that as long as the partition is mounted sync, this isn't
a problem.
I have seen reports where ext3 caused the data corruption (old kernels,
2.4.4 and before I believe) problem, not ext2. I.e. the addition of
journaling caused data loss.
Given that possibility, it may well have been at one time that ext2 was a
safer bet than ext3.
> > perhaps even including performance metrics for *BSD. That, not
> > Linux-baiting, is the answer...
>
> I didn't see anyone Linux-baiting.
No more than the typical, light hearted stuff we toss back and forth. I
certainly wasn't upset by any of it.
