First off, would you care to quote chapter and verse of these
"defined semantics" ? Do you mean the BSD source?
Traditional FFS/UFS achieves "safety" at a terrible cost to
performance. I can barely stand the wait to untar XFree86 on Solaris8
on a PII-333, even with UFS logging -- I'd rather use my Pentium 166
laptop running Linux! ext2 solved this performance issue many years
ago by recognizing that the FFS metadata scheme was not really safe
either; instead the intelligence was put into e2fsck, and where
necessary, the applications. (Do I hear faint echoes of the
"lint" v. "cc" design criterion ... ?)
The infrastructure is now in place to solve these problems in ext3,
without imposing a least-common-denominator approach that degrades
overall system performance. In these instances "Linus is right" when
he notes that (1) the proposed immediate solution does not really solve
the problem, and (2) once in there, developers will rely on its precise
semantics, making them difficult to get right later on, and providing
no incentive to do so. In many such instances "undefined" behavior is
the best intermediate solution.
As one can see from the "gkernel-commit" traffic, Andrew Morton has
not only taken away useful information from this thread, he's already
halfway to a solution, in just a day, because Matthias Andree took
the time to describe the functional requirements instead of just
whining that "it's not like BSD."
> Thus why all reasonably paranoid MTAs and other mail programs say "use
> chattr +S on ext2"---we need ordered metadata writes.
And that's precisely the type of thing we want -- unused features should
not impact the rest of the system.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/