>>>>> "jh" == Johan Hartzenberg <jhartzen@XXX> writes:
jh> Regarding the second type there has been a few bugs in the ZFS
jh> code, but compared to the bugs in other file systems,
jh> remarkibly few.
fine, provided you replace ``other filesystems'' with ``other
brand-new unproven filesystems.''
I believe there are more unresolved reports of corruption with ZFS
than with UFS or ext3.
The things that bother me about the ZFS corruption reports:
* for the mailing list posters, there's no followup. The people
using ZFS roughly and experiencing corruption seem to tend to be
the ones without support contracts.
except for the one case of the guy with iSCSI that said, ``be sure
to have ZFS-level redundancy if you're using iSCSI to vendor RAID
storage hardware''. For him it almost sounded as if he'd asked for
support, and they told him ``sorry you're SOL. we've root-caused
the problem, and the workaround is, use ZFS-level redundnacy. no
other fix is available in stable Solaris.'' He did not say that,
though, I'm guessing. I suppose we should find the post and ask
him.
* since ZFS has no fsck tool, it can't seem to make up its mind about
how aggressive to be in recovering. For UFS, FFS, ext3, reiser,
XFS filesystems, the fsck tool sort of switched into an aggressive
mode, ``manual intervention required'' and the manual intervention
was basically to just say ``fsck --simon-sez'' and cross your
fingers. The meaning was, ``try to recover as much data as
possible, admitting that you've failed to keep your integrity
guarantees.'' There's no such mode with ZFS. There is some
handling of sporadic checksum errors, but the special-cases for
invalid metadata don't seem to be fully fleshed out.
with ZFS, like many other obnoxious tools in Solaris, it is often
extremely obsinate about not letting you do something which it
thinks could cause strange behavior. I think its short implicit
fsck on import is very conservative, and if it rejects your pool,
there is no recourse, no --simon-sez switch.
this is arguably a good approach. It should be a goal that
eventually you can import any sequence of bits without ever
panicing the kernel (though that doesn't seem to be the case now).
And corruption caused by bugs should be fixed at the source, not
after the fact---either one accomplishes the same thing, except for
people using out-of-date software, who, once things settle down,
shouldn't exist.
but they've yet to prove it's a good approach, and that they can
actually finish at the level of quality required to make it valid.
And sometimes it seems like they care more about never having to
say, ``yes, you paid for support, and no, we lack the resources and
talent to fix your problem,'' than they do about writing a system
least likely to lose data. I'm concerned that this lack of a
--simon-sez flag has more to do with blaming you rather than Sun
for losing data, than it does for actually believing in the good
approach I described in the last paragraph. The meaning of the
flag, ``admit you've failed to keep your integrity guarantees, and
proceed with recovery,'' is I think something they never want to
express. The fact that checksum errors are blamed on
disk/cable/controller problems but occur in other circumstances
further argues for this mindset. and if that approach is going to
pervade the entire filesystem's design, or at least the real
recovery features are going to be sealed behind a user interface
that tries to blame the operator and prevent his taking certain
recovery actions, it'll be a really significant unattractive
feature.
Attachment:
pgpQ5YWQtJ919.pgp
Description: PGP signature