On Thu, 17 Jul 2008, James C. McPherson wrote: > ... >> MPXIO is quite ugly and rough around the edges (at least compared with >> ZFS) but it works. > > Just curious - what do you see as the ugliness in MPxIO? I don't > have an agenda to push, I'd just like to get feedback from you > on what you see as opportunities for improvement.
The most obvious thing is the ungainly long device names and the odd requirement to update /etc/vfstab. The other thing I noticed is that while 'mpathadm' works as documented, it lacks in user friendlyness. It almost always requires executing a command to show what is available, and then doing a specific query based on the items listed. A few 'composite' type commands which list the devices along with certain commonly requested information would be useful. Currently we get a list of logical units and then we do 'show lu' to dump massive amounts of detail. When there are large amounts of logical units (as I have) this approach becomes overwelming if all I want to learn is the current path status for the devices in a ZFS pool. When I first used 'stmsboot -e' (as the StorageTek 2540 docs recommend), it caused my system not to boot since it uses SAS disks and there were apparently problems with local SAS disks at that time (and it sounds like there still is). I learned the hard way to only request multipath for what actually needs it. Here is a small work-around script I coded up recently to list path status: #!/bin/sh # Test path access to multipathed devices devs=`mpathadm list lu | grep /dev/rdsk/` for dev in $devs do echo "=== $dev ===" mpathadm show lu $dev | grep 'Access State' done It should provide a small example of useful composite functionality (which can obviously be far better than my script!). Bob _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
