zfs discuss - Feb 2011 - multipath used inadvertantly?

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

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 at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
>

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

Hi Ray,

MPxIO is on by default for x86 systems that run the Solaris 10 9/10
release.

On my Solaris 10 9/10 SPARC system, I see this:

# stmsboot -L
stmsboot: MPxIO is not enabled
stmsboot: MPxIO disabled

You can use the stmsboot CLI to disable multipathing. You are prompted
to reboot the system after disabling MPxIO. See stmsboot.1m for more
info.

With an x86 whitebox, I would export your ZFS storage pools first,
but maybe it doesn''t matter if the system is rebooted.

ZFS should be able to identify the devices by their internal device
IDs but I can''t speak for unknown hardware. When you make hardware
changes, always have current backups.

Thanks,

Cindy

On 02/15/11 14:32, Ray Van Dolson wrote:
> 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
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Thanks Cindy.

Are you (or anyone else reading) aware of a way to disable MPxIO at
install time?

I imagine there''s no harm* in leaving MPxIO enabled with single-pathed
devices -- we''ll likely just keep this in mind for future installs.

Thanks,
Ray

* performance penalty -- we do see errors in our logs from time to time
  from mpathd letting us know disks have only one path

On Tue, Feb 15, 2011 at 01:50:47PM -0800, Cindy Swearingen
wrote:
> Hi Ray,
> 
> MPxIO is on by default for x86 systems that run the Solaris 10 9/10
> release.
> 
> On my Solaris 10 9/10 SPARC system, I see this:
> 
> # stmsboot -L
> stmsboot: MPxIO is not enabled
> stmsboot: MPxIO disabled
> 
> You can use the stmsboot CLI to disable multipathing. You are prompted
> to reboot the system after disabling MPxIO. See stmsboot.1m for more
> info.
> 
> With an x86 whitebox, I would export your ZFS storage pools first,
> but maybe it doesn''t matter if the system is rebooted.
> 
> ZFS should be able to identify the devices by their internal device
> IDs but I can''t speak for unknown hardware. When you make hardware
> changes, always have current backups.
> 
> Thanks,
> 
> Cindy
> 
> On 02/15/11 14:32, Ray Van Dolson wrote:
> > 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