Miles Nordin <[EMAIL PROTECTED]>
>>>>> "cs" == Cromar Scott <[EMAIL PROTECTED]> writes:
cs> It appears that the metadata on that pool became corrupted
cs> when the processor failed. The exact mechanism is a bit of a
cs> mystery,
[...]
cs> We were told that the probability of metadata corruption would
cs> have been reduced but not eliminated by having a mirrored LUN.
cs> We were also told that the issue will be fixed in U6.
mn> how can one fix an issue which is a bit of a
mn> mystery? Or do you mean the lazy-panic issue
mn> is fixed, but the corruption issue is not?
We opened a call with Sun support. We were told that the corruption
issue was due to a race condition within ZFS. We were also told that
the issue was known and was scheduled for a fix in S10U6.
Sun support recommended that we use a mirrored pool to reduce the
possibility of the bug re-emerging, but they told us that even a
mirrored pool might be subject to the same bug.
Moving to OpenSolaris was not an option due to the nature of the
application and our requirement for support. It is possible that we
might have been able to move to SVM and UFS rather than VxVM and VxFS,
but we were bumping up against our deadline, and we knew from previous
deployments that VxVM and VxFS would work. (And we had the management
infrastructure in place to deal with Veritas.)
We run ZFS in several other environments with different availability
requirements, but we were hoping to start using it across the board as a
VxVM/VxFS replacement.
--Scott
This message may contain information that is confidential or privileged.
If you are not the intended recipient, please advise the sender immediately
and delete this message.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
