in.mpathd is the IP multipath daemon. (Yes, it's a bit confusing that
mpathadm is the storage multipath admin tool. )
If scsi_vhci is loaded in the kernel you have storage multipathing
enabled. (Check with modinfo.)
On 2/15/2011 3:53 PM, Ray Van Dolson wrote:
I'm troubleshooting an existing Solaris 10U9 server (x86 whitebox) and
noticed its device names are extremely hair -- very similar to the
multipath device names: c0t5000C50026F8ACAAd0, etc, etc.
mpathadm seems to confirm:
# mpathadm list lu
/dev/rdsk/c0t50015179591CE0C1d0s2
Total Path Count: 1
Operational Path Count: 1
# ps -ef | grep mpath
root 245 1 0 Jan 05 ? 16:38 /usr/lib/inet/in.mpathd -a
The system is SuperMicro based with an LSI SAS2008 controller in it.
To my knowledge it has no multipath capabilities (or at least not as
its wired up currently).
The mpt_sas driver is in use per prtconf and modinfo.
My questions are:
- What scenario would the multipath driver get loaded up at
installation time for this LSI controller? I'm guessing this is what
happened?
- If I disabled mpathd would I get the shorter disk device names back
again? How would this impact existing zpools that are already on the
system tied to these disks? I have a feeling doing this might be a
little bit painful. :)
I tried to glean the "original" device names from stmsboot -L, but it
didn't show any mappings...
Thanks,
Ray
_______________________________________________
storage-discuss mailing list
storage-disc...@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
