A LUN "going away" should not cause a panic. (The obvious exception
being the boot LUN) If mpxio saw the LUN move and everything moved ...
then it's a bug. The panic backtrace will point to the guilty party in
any case.
Jason J. W. Williams wrote:
Hi Robert,
MPxIO had correctly moved the paths. More than one path to controller
A was OK, and one patch to controller A for each LUN was active when
controller B was rebooted. I have a hunch that the array was at
fault, because it also rebooted a Windows server with LUNs only on
Controller A. In the case of the Windows server Engenios RDAC was
handling multipathing. Overall, not a big deal, I just wouldn't trust
the array to do a hitless commanded controller failover or firmware
upgrade.
-J
On 12/22/06, Robert Milkowski <[EMAIL PROTECTED]> wrote:
Hello Jason,
Friday, December 22, 2006, 5:55:38 PM, you wrote:
JJWW> Just for what its worth, when we rebooted a controller in our
array
JJWW> (we pre-moved all the LUNs to the other controller), despite using
JJWW> MPXIO ZFS kernel panicked. Verified that all the LUNs were on the
JJWW> correct controller when this occurred. Its not clear why ZFS
thought
JJWW> it lost a LUN but it did. We have done cable pulling using
ZFS/MPXIO
JJWW> before and that works very well. It may well be array-related
in our
JJWW> case, but I hate anyone to have a false sense of security.
Did you first check (with format for example) if LUNs were really
accessible? If MPxIO worked ok and at least one path is ok then ZFS
won't panic.
--
Best regards,
Robert mailto:[EMAIL PROTECTED]
http://milek.blogspot.com
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
