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
