Thanks Torrey.  I definitely see that multipathing is enabled... I
mainly want to understand whether or not there are installation
scenarios where multipathing is enabled by default (if the mpt driver
thinks it can support it will it enable mpathd at install time?) as
well as the consequences of disabling it now...

It looks to me as if disabling it will result in some pain. :)

Ray

On Tue, Feb 15, 2011 at 01:24:20PM -0800, Torrey McMahon wrote:
> 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-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss

Reply via email to