From mpathd or from scsi_vhci? If they're scsi_vhci it's probably the
"we found a device with one path and it's optimal" message, right?
On 2/15/2011 5:14 PM, Ray Van Dolson wrote:
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
_______________________________________________
storage-discuss mailing list
storage-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
storage-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
