>>>>> "g" == Gino  <dandr...@gmail.com> writes:

     g> we lost many zpools with multimillion$ EMC, Netapp and
     g> HDS arrays just simulating fc switches power fails.  

     g> The problem is that ZFS can't properly recover itself.

I don't like what you call ``the problem''---I think it assumes too
much.  You mistake *A* fix for *THE* problem, before we can even agree
for sure on, what is the problem.  The problem may be in the solaris
FC initiator, in a corner case of the FC protocol itself, or in ZFS's
exception handling when a ``SYNCHRONIZE CACHE'' command returns
failure.

It's likely other filesystems are affected by ``the problem'' as I
define it, just much less so.  If that's the case, it'd be much better
IMHO to fix the real problem once and for all, and find it so that it
stays fixed, than to make ZFS work around it by losing a tiny bit of
data instead of the whole pool.  I don't think ZFS should feel
entitled to brag about protection from Silent Corruption, if it were
at the same time willing to silently boot without a slog, or silently
rollback to an earlier ueberblock, or if it acts like a cheap USB
stick when an FC switch reboots (by quietly losing things that were
written long ago).  

That's something else to think of: if what's happening is what we
think is happening, then you may be having ``the problem'' at other
times when you do not lose pools!

I'm a fan of availability and not of ZFS's lazy panics and peppering
of assertions, but I'm starting to come around a little bit: I don't
want to miss an opportunity to raise everyone's expectations of their
storage stacks, to finally hold cheating disk vendors, cheating
virtualization software vendors, and lazy iSCSI programmers
accountable, and to make the exception handling in ZFS actually
capable of dealing with modern storage instead of hanging status
commands, hanging NFS stacks, and inability to replay writes.

Attachment: pgp3oxugxx2KY.pgp
Description: PGP signature

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to