>>>>> "gs" == Greg Shaw <[EMAIL PROTECTED]> writes:
gs> Nevada isn't production code. For real ZFS testing, you must
gs> use a production release, currently Solaris 10 (update 5, soon
gs> to be update 6).
based on list feedback, my impression is that the results of a
``test'' confined to s10, particularly s10u4 (the latest available
during most of Mike's experience), would be worse than Nevada
experience over the same period. but I doubt either matches UFS+SVM
or ext3+LVM2. The on-disk format with ``ditto blocks'' and ``always
consistent'' may be fantastic, but the code for reading it is not.
Maybe the code is stellar, and the problem really is underlying
storage stacks that fail to respect write barriers. If so, ZFS needs
to include a storage stack qualification tool. For me it doesn't
strain credibility to believe these problems might be rampant in VM
stacks and SAN's, nor do I find it unacceptable if ZFS is vastly more
sensitive to them than any other filesystem. If this speculation
turns out to really be the case, I imagine the two going together: the
problems are rampant because they don't bother other filesystems too
catastrophically. If this is really the situation, then ZFS needs to
give the sysadmin a way to isolate and fix the problems
deterministically before filling the pool with data, not just blame
the sysadmin based on nebulous speculatory hindsight gremlins.
And if it's NOT the case, the ZFS problems need to be acknowledged and
fixed.
To my view, the above is *IN ADDITION* to developing a
recovery/forensic/``fsck'' tool, not either/or. The pools should not
be getting corrupt in the first place, and pulling the cord should not
mean you have to settle for best-effort. None of the modern
filesystems demand an fsck after unclean shutdown.
The current procedure for qualifying a platform seems to be: (1)
subject it to heavy write activity, (2) pull the cord, (3) repeat.
Ahmed, maybe you should use that test to ``quantify'' filesystem
reliability. You can try it with ZFS, then reinstall the machine with
CentOS and try the same test with ext3+LVM2 or xfs+areca. The numbers
you get are how many times can you pull the cord before you lose
something, and how much do you lose. Here's a really old test of that
sort comparing Linux filesystems which is something like what I have
in mind:
https://www.redhat.com/archives/fedora-list/2004-July/msg00418.html
so you see he got two sets of numbers---number of reboots and amount
of corruption. For reiserfs and JFS he lost their equivalent of ``the
whole pool'', and for ext3 and XFS he got corruption but never lost
the pool. It's not clear to me the filesystems ever claimed to
prevent corruption in his test scenario (was he calling fsync() after
each log write? syslog does that sometimes, and if so, they do claim
it, but if he's just writing with some silly script they don't), but
definitely they do all claim you won't lose the whole pool in a power
outage, and only two out of four delivered on that. I base my choice
of Linux filesystem on this test, and wish I'd done such a test before
converting things to ZFS.
pgpi0TlEstn85.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
