Hannes, Does multipath= and the scanning issue apply to zSeries using the zfcp driver? If the scanning is initiated in a level sitting on top of (I'm assuming)or higher than zfcp driver and the zfcp driver doesn't support scanning isn't it in effect a sort of null-op that zfcp ignores because it can't do it?
" Configuring the zfcp device driver- The zfcp device driver currently does not perform any port discovery or LUN scanning to determine the ports and LUNs in the SAN. Every port and LUN in the SAN that should be accessed via zfcp must be configured explicitly. Once a port and a LUN are properly configured and the adapter is set online a new SCSI device is registered at the SCSI stack." Tia -------------------------------------------------------- This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Hannes Reinecke Sent: Tuesday, September 19, 2006 10:20 AM To: [email protected] Subject: Re: SLES9 scsi multipath initrd-linuxrc question On Tue, Sep 19, 2006 at 08:23:54AM -0400, Romanowski, John (OFT) wrote: > Hannes, > I'm confused that SLES 9 added a parameter, multipath=, to switch "off > multipathing in the initrd, > ie for the root fs" > > but Novell says specifically for SLES 9 that "Currently, DM MPIO is not > available for either the rooti > or the boot partition, as the boot loader does not know how to handle MPIO." > Argl. No, it's me getting confused. The multipath parameter in SLES9 is actually an evil hack which switches of the partition detection from the block layer. It's never meant to be a properly documented boot parameter, more something of a performance tweak. Main reason here is that _reading_ from a disk (as the partition scanning code does) might trigger failover on certain arrays, which again might take some time for the failover to occur. And as the devices are scanned sequentially, you might end up failing the path back and forth several times, each time encountering the time penalty for switching paths. We had someone where this partition table scanning alone took several hours to complete. The statement about SLES9 and multipathing on root not supported still stands. Cheers, Hannes -- Dr. Hannes Reinecke [EMAIL PROTECTED] SuSE Linux Products GmbH S390 & zSeries Maxfeldstra e 5 +49 911 74053 688 90409 N rnberg http://www.suse.de ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
