>>>>> "dm" == David Magda <dma...@ee.ryerson.ca> writes:
dm> is this what POSIX actually specifies?
i doubt it. If it did, it would basically mandate a log-structured /
COW filesystem, which, although not a _bad_ idea, is way too far from
a settled debate to be enshrining in a mandatory ``standard'' (ex.,
the database fragmentation problems with LFS, WaFL, ZFS. And the
large number of important deployed non-COW filesystems on POSIX
systems).
There's no other so-far-demonstrated way than log-structured/COW to
achieve this property which some people think they're entitled to take
for granted: ``after a reboot, the system must appear as though it did
not reorder any writes. The filesystem must recover to some exact
state that it passed through in the minutes leading up to the crash,
some state as observed from the POSIX userland (above all write
caches).''
It's a nice property. Nine years ago when i was trying to get Linux
users to try NetBSD, I flogged this as a great virtue of LFS. And if
I were designing a non-POSIX operating system to replace Unix, I'd
probably promise developers this property. But achieving it is just
too constraining to belong in POSIX.
If you can find some application that can safely disable some safety
feature when it knows it's running on ZFS that it needs to keep on
other filesystems and thus perform absurdly faster on ZFS with no
risk, then you can demonstrate the worth of promising this property.
The fsync() that i'm sure KDE will add into all their broken apps is
such an example, but I doubt it will be ``absurdly faster'' enough to
get ZFS any attention. Maybe something to do with virtual disk
backing stores for VM's?
But I don't think pushing exaggerated expectations as ``obvious'' in
front of people who don't know the nasty details yet, nor overstating
POSIX's minimal crash requirements, is going to work. There are just
too many smart people ready to defend the non-log-stuctured
write-in-place filesystems. And I believe it *is* possible to write a
correct database or MTA, even with the level of guarantee those
systems provide (provide in practice, not provide as specified by
POSIX).
And the guarantees ARE minimal---just:
http://www.google.com/search?q=POSIX+%22crash+consistency%22
and you'll find even people against T'so's who want to change ext4
still agree POSIX is on T'so's side.
My own opinion is that the apps are unportable and need to be fixed,
and that what te side against T'so wants changed is so poorly stated
it's no more than ad-hoc ``make the apps not broken, because otherwise
anything which does the exact same thing as the broken app we just
found will also be broken!!!'' it's not a clearly articulatable
guarantee like that AIUI provided by transaction groups.
But linux app developers never seem to give much of a flying shit
whether their apps work on notLinux, which is why they think it's
``practical'' to change ext4 rather than the nonconformant app, so
dragging out the POSIX horse for flogging in support of ``change
ext4'' looks highly hypocritical, while flogging the same horse to
support ``ZFS is the only POSIXly correct filesystem on the planet''
is flatly incorrect but at least not hypocritical. :)
pgp6S7cxYCPf9.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
