Because as far as the VFS is concerned, they do not happen. As far as the
_design_ is concerned, writes are protected by the VFS layer, and if
somebody decides to then undo that protection, at that point I no longer
care - but that "somebody" had better be ready to do lots of extra work.
To me, what matters is not whether ext2 is ugly or not. Cruft that doesn't
impact others I don't care about, and I'm not on a crusade to fix old
cruft.
What matters is (a) that the design is maintainable and (b) that we don't
add _more_ cruft. (a) is why I will consider writes to be atomic from an
interface standpoint. (b) is why I would much prefer to have a "jfs" than
an "ext3".
(a) is why I consider it completely acceptable to do DMA into the page
cache, but very unacceptable to do DMA into user space (the "page cache"
in question could easily be mapped somewhere, and wouldn't necessarily
even have to be backed by a file, but do you see the _design_ issue?).
I certainly see your argument about "make something work quickly - base it
on ext2". However, while _you_ may consider this a stop-gap measure, _I_
know that we may end up being red in the face over some bad design when it
turns out three years later that people are still using the stop-gap
measure, and the stop-gap measure was good enough that nobody ever
bothered to design something nice.
FAT32 was a "stop-gap measure". Sure, it made sense to just extend FAT
from a "we need to have something that can handle larger filesystems NOW"
standpoint. But stop-gap measures have a way of staying around. Forever.
I would hope that Linux development is not guided by those kinds of
constraints. If we have to wait an extra year for a journaling filesystem,
I don't think it's a bad tradeoff to discuss the possibility of just
starting from a clean slate.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/