Earlier versions of multipath-tools had a hard coded vendor and model for DASDs. The tools just used "IBM" and "S/390 DASD ECKD"
Mit freundlichem Gruß / Regards, Stefan Bader SW Linux on zSeries Development [EMAIL PROTECTED] IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 ---------------------------------------------------------------------------------- When all other means of communication fail, try words. Linux on 390 Port <[email protected]> wrote on 15.06.2007 15:58:33: > I have device-mapper-multipath-0.4.5-16.1.RHEL4, but based on what I > saw, I don't see how this can be fixed without an update to the > kernel driver. The driver at the U4 level doesn't export vendor and > model info into sysfs, so there doesn't appear to be any way for > device-mapper-multipath to identify a rule set for dasd. > > I know this was fixed in RHEL5. > > From /sys/bus/ccw/devices/0.0.0100] on RHEL4: > > availability cmb_enable detach_state discipline readonly > block cutype devtype online use_diag > > From /sys/bus/ccw/devices/0.0.0100] on RHEL5: > > alias bus devtype eer_enabled readonly uid > availability cmb_enable discipline modalias subsystem use_diag > block:dasda cutype driver online uevent vendor > > > Is there a kernel for RHEL4 that supports this? > > Incidentally, the default configuration under RHEL5 still uses > volume label to match up pairs, but that's prone to problems if you > have a mix of dedicated devices and minidisks, and happen to end up > with a duplicate label. There's a "uid" field in sysfs now, > wouldn't it make more sense to use that? > > > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf > Of Stefan Bader > Sent: Friday, June 15, 2007 9:26 AM > To: [email protected] > Subject: Re: [LINUX-390] PAV and RHEL 4 issue, not found on pathvec > > > Hm, update 4. Which device-mapper-multipath package is that? Found the > following on RHN: > > device-mapper-multipath-0.4.5-21.RHEL4-s390x > -device-mapper-multipath is now able to handle DASD devices > > Mit freundlichem Gruß / Regards, > Stefan Bader > > SW Linux on zSeries Development > [EMAIL PROTECTED] > > IBM Deutschland Entwicklung GmbH > Vorsitzender des Aufsichtsrats: Martin Jetter > Geschäftsführung: Herbert Kircher > Sitz der Gesellschaft: Böblingen > Registergericht: Amtsgericht Stuttgart, HRB 243294 > ---------------------------------------------------------------------------------- > When all other means of communication fail, try words. > > Linux on 390 Port <[email protected]> wrote on 15.06.2007 15:16:27: > > > My multipath.conf (not including commented lines) > > > > defaults { > > user_friendly_names yes > > } > > devices { > > device { > > vendor "IBM" > > product "S/390 DASD ECKD" > > path_grouping_policy multibus > > getuid_callout "/sbin/dasdview -j -f /dev/%n" > > path_checker directio > > } > > } > > > > My rhel version is: > > > > Red Hat Enterprise Linux AS release 4 (Nahant Update 4) > > 2.6.9-42.EL #1 SMP Wed Jul 12 23:21:43 EDT 2006 s390x s390x s390x > GNU/Linux > > > > Thanks! > > Eric > > > > Stefan Bader wrote: > > > Yes, with older kernels you have to stay with dasdview and the labels. > > > > Unfortunately this isn't > > > quaranteed to be unique. But it is the only way for older kernels. > > > About the blacklist_execptions: I guess it will depend on the service > > > level of RHEL4 whether > > > the keyword actually is in or not. We would have to check the current > and > > > latest version numbers. > > > what did you put into blacklist_exceptions? The statement that should > > > enable all DASDs should > > > be: > > > > > > blacklist_execptions { > > > device { > > > vendor "IBM" > > > product "S/390 DASD.*" > > > } > > > } > > > > > > Eric's problem seems to be a bit stranger. The "not found in pathvec" > (yes > > > that is more of an informational > > > statement) indicates the scan found the DASD devices. But after that, > > > there is no probing to the devices > > > at all. > > > Just to make sure I don't miss anything: which level of RHEL4 are we > > > talking? And how does the multipath.conf > > > (only lines that are not commented out) look like? > > > > > > Mit freundlichem Gruß / Regards, > > > Stefan Bader > > > > > > SW Linux on zSeries Development > > > [EMAIL PROTECTED] > > > > > > IBM Deutschland Entwicklung GmbH > > > Vorsitzender des Aufsichtsrats: Martin Jetter > > > Geschäftsführung: Herbert Kircher > > > Sitz der Gesellschaft: Böblingen > > > Registergericht: Amtsgericht Stuttgart, HRB 243294 > > > > > > ---------------------------------------------------------------------------------- > > > When all other means of communication fail, try words. > > > > > > Linux on 390 Port <[email protected]> wrote on 15.06.2007 > 14:28:41: > > > > > > > > >> I spent a lot of time going around with this. The problem seemed to > > >> come down to that with the kernel I'm using (2.6.9-42.0.8), the dasd > > >> driver doesn't provide vendor and model info in sysfs, so device- > > >> mapper-multipath can't match up the devices with a rule set. The > > >> newer driver in RHEL5 does provide this, and I was able to get it to > > >> work there. If someone else has found a workaround, I'd love to > > >> hear it, because we have situations where we'd love to use PAVs, and > > >> have been assuming they're not supported till RHEL5. > > >> > > >> Incidentally, the "pathvec" message seems to be semi-normal. It > > >> also shows up on our multipath FCP devices, but they do work. > > >> > > >> There's also a syntax issue with the blacklist section of the > > >> multipath.conf file, at least on RHEL5. The default blacklist > > >> includes dasd*, but there's a "blacklist exceptions" section that's > > >> supposed to override this by vendor/model code. That section is > > >> invalid unless there's a "blacklist" section, so you can't remove > > >> the blacklist entirely. You need to put SOMETHING in the blacklist, > > >> even if it's bogus. The "exceptions" bit doesn't appear to work > > >> anyway, if "dasd*' is in the blacklist, the devices won't be > examined. > > >> > > >> One more problem was that the mapper uses dasdview to pull the > > >> labels from the devices, and uses the labels to match up devices. > > >> If you're using minidisks for your non-PAV devices, and you happen > > >> to have a duplicate volume label, the mapper creates a multipath > > >> group for the pair (in our case, it was / and /var), and they're > > >> marked "busy". When the script tries to mount them by base device > > >> node, the mounts fail, and the boot process stops. > > >> > > >> -----Original Message----- > > >> From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf > > >> Of Stefan Bader > > >> Sent: Friday, June 15, 2007 7:37 AM > > >> To: [email protected] > > >> Subject: Re: [LINUX-390] PAV and RHEL 4 issue, not found on pathvec > > >> > > >> > > >> Hi Eric, > > >> > > >> short answer: if "multipath -ll" doesn't show anything, your setup > still > > >> > > > > > > > > >> isn't correct. Now for some more information. > > >> Is the output of "multipath -v3" that you sent complete? It sound a > bit > > >> strange. If DASDs aren't blacklisted there > > >> should be some action. The "not found in pathvec" is normal for an > > >> inittial run. It just says there hasn't been any > > >> information about the paths gathered, yet. > > >> You might increase the verbosity level to 6 and send it (proably to > me > > >> directly, since it gets quite large). So we might see why > > >> the multipath volumes aren't created. > > >> > > >> Mit freundlichem Gruß / Regards, > > >> Stefan Bader > > >> > > >> SW Linux on zSeries Development > > >> [EMAIL PROTECTED] > > >> > > >> IBM Deutschland Entwicklung GmbH > > >> Vorsitzender des Aufsichtsrats: Martin Jetter > > >> Geschäftsführung: Herbert Kircher > > >> Sitz der Gesellschaft: Böblingen > > >> Registergericht: Amtsgericht Stuttgart, HRB 243294 > > >> > > >> > > > > > > ---------------------------------------------------------------------------------- > > > > > >> When all other means of communication fail, try words. > > >> > > >> Linux on 390 Port <[email protected]> wrote on 14.06.2007 > > >> > > > 17:49:17: > > > > > >>> This is not the exact issue I am seeing... > > >>> > > >>> Here are my results and this is the case before and after the change > > > >>> > > > to > > > > > >>> multipath.conf per the bugz workaround. > > >>> > > >>> # multipath > > >>> # > > >>> # multipath -v3 > > >>> load path identifiers cache > > >>> # > > >>> # all paths in cache : > > >>> # > > >>> path dasda not found in pathvec > > >>> > > >>> ===== path info dasda (mask 0x1f) ===== > > >>> path dasdb not found in pathvec > > >>> > > >>> ===== path info dasdb (mask 0x1f) ===== > > >>> path dasdc not found in pathvec > > >>> > > >>> ===== path info dasdc (mask 0x1f) ===== > > >>> path dasdd not found in pathvec > > >>> > > >>> ===== path info dasdd (mask 0x1f) ===== > > >>> md0 blacklisted > > >>> ram0 blacklisted > > >>> ram10 blacklisted > > >>> ram11 blacklisted > > >>> ram12 blacklisted > > >>> ram13 blacklisted > > >>> ram14 blacklisted > > >>> ram15 blacklisted > > >>> ram1 blacklisted > > >>> ram2 blacklisted > > >>> ram3 blacklisted > > >>> ram4 blacklisted > > >>> ram5 blacklisted > > >>> ram6 blacklisted > > >>> ram7 blacklisted > > >>> ram8 blacklisted > > >>> ram9 blacklisted > > >>> > > >>> Interesting enough though iostat has the exact same stats for both > > >>> /dev/dasdb and /dev/dasdd and when running pvscan I receive the > > >>> > > >> following: > > >> > > >>> dasdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 > > >>> 0.00 22.67 0.00 23.33 13.33 0.00 > > >>> dasdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 > > >>> 0.00 22.67 0.00 21.67 13.33 0.00 > > >>> > > >>> pvscan > > >>> Found duplicate PV sAHQBBquhyI5mbrj8QdvW3zM4YKXjEod: using > > >>> > > > /dev/dasdd1 > > > > > >>> not /dev/dasdb1 > > >>> PV /dev/dasdd1 lvm2 [2.29 GB] > > >>> Total: 1 [2.29 GB] / in use: 0 [0 ] / in no VG: 1 [2.29 GB] > > >>> > > >>> So my question is, is PAV working or not? If it is how can I be > > >>> > > > certain > > > > > >>> it is? multipath -ll returns no data that would lead me to believe > > >>> multipathing is working. > > >>> > > >>> Thoughts / assistance? > > >>> > > >>> Thanks! > > >>> > > >>> > > >>> Bradford Hinson wrote: > > >>> > > >>>> This looks related to: > > >>>> > > >>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238983 > > >>>> > > >>>> (see error msg at end of comment 0) > > >>>> > > >>>> On Thu, 2007-06-14 at 08:56 -0400, Eric Sammons wrote: > > >>>> > > >>>> > > >>>>> Hi, > > >>>>> > > >>>>> I am trying to configure PAV on RHEL 4 and am running into a > > >>>>> > > > problem. > > > > > >> I > > >> > > >>>>> have been working from the "How to Improve Performance with PAV > > >>>>> > > >> November > > >> > > >>>>> 17, 2006" document. > > >>>>> > > >>>>> So it appears PAV is configured. > > >>>>> > > >>>>> i.e. > > >>>>> > > >>>>> DASD 0100 ON DASD 304F R/W 0X0100 SUBCHANNEL = 0000 > > >>>>> *DASD 0101 ON DASD 314F R/W 0X0101 SUBCHANNEL = 0001* > > >>>>> DASD 0190 3390 520RES R/O 107 CYL ON DASD 300B SUBCHANNEL > = > > >>>>> > > > > > > > > >> 0008 > > >> > > >>>>> DASD 0191 3390 VM350B R/O 470 CYL ON DASD 350B SUBCHANNEL > = > > >>>>> > > > > > > > > >> 000C > > >> > > >>>>> DASD 019D 3390 V01W01 R/O 146 CYL ON DASD 330B SUBCHANNEL > = > > >>>>> > > > > > > > > >> 0009 > > >> > > >>>>> DASD 019E 3390 V01W01 R/O 250 CYL ON DASD 330B SUBCHANNEL > = > > >>>>> > > > > > > > > >> 000A > > >> > > >>>>> DASD 0200 9336 (VDSK) R/W 524288 BLK ON DASD VDSK SUBCHANNEL > = > > >>>>> > > > > > > > > >> 0016 > > >> > > >>>>> *DASD 0201 ON DASD 31B0 R/W 0X0101 SUBCHANNEL = 0002* > > >>>>> DASD 0592 3390 V01W01 R/O 67 CYL ON DASD 330B SUBCHANNEL > = > > >>>>> > > > > > > > > >> 000B > > >> > > >>>>> # vmcp q pav 314f > > >>>>> Device 314F is a base Parallel Access Volume with the following > > >>>>> > > >> aliases: > > >> > > >>>>> 31B0 > > >>>>> > > >>>>> However, after loading the kernel module: > > >>>>> dm_multipath 43792 0 > > >>>>> > > >>>>> and starting multipathd, oh and modifying the /etc/multipath.conf > > >>>>> > > > to > > > > > >>>>> comment out the blacklist (and yes I modified the file before > > >>>>> > > >> starting > > >> > > >>>>> multipathd) I still get no results when I run mulipath. > > >>>>> > > >>>>> > > >>>>> # multipath > > >>>>> # > > >>>>> > > >>>>> When I run multipath -v3 -d I get the following: > > >>>>> > > >>>>> load path identifiers cache > > >>>>> ux_socket_connect error > > >>>>> # > > >>>>> # all paths in cache : > > >>>>> # > > >>>>> path dasda not found in pathvec > > >>>>> > > >>>>> ===== path info dasda (mask 0x1f) ===== > > >>>>> path dasdb not found in pathvec > > >>>>> > > >>>>> ===== path info dasdb (mask 0x1f) ===== > > >>>>> path dasdc not found in pathvec > > >>>>> > > >>>>> ===== path info dasdc (mask 0x1f) ===== > > >>>>> path dasdd not found in pathvec > > >>>>> > > >>>>> ===== path info dasdd (mask 0x1f) ===== > > >>>>> md0 blacklisted > > >>>>> ram0 blacklisted > > >>>>> ram10 blacklisted > > >>>>> ram11 blacklisted > > >>>>> ram12 blacklisted > > >>>>> ram13 blacklisted > > >>>>> ram14 blacklisted > > >>>>> ram15 blacklisted > > >>>>> ram1 blacklisted > > >>>>> ram2 blacklisted > > >>>>> ram3 blacklisted > > >>>>> ram4 blacklisted > > >>>>> ram5 blacklisted > > >>>>> ram6 blacklisted > > >>>>> ram7 blacklisted > > >>>>> ram8 blacklisted > > >>>>> ram9 blacklisted > > >>>>> > > >>>>> > > >>>>> I am concerned about the ux_socket_connect error and the not found > > > >>>>> > > > in > > > > > >>>>> pathvec errors. Anyone know what might be going on here? Am I > > >>>>> > > >> missing > > >> > > >>>>> something here? > > >>>>> > > >>>>> thanks! > > >>>>> Eric > > >>>>> > > >>>>> > > >>>>> > > >> > ---------------------------------------------------------------------- > > >> > > >>>>> 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 > > >>>>> > > >>>>> > > >>>> -- > > >>>> Brad Hinson <[EMAIL PROTECTED]> > > >>>> Technical Account Manager > > >>>> Red Hat, Inc. > > >>>> (888) 733-4281 x44198 > > >>>> > > >>>> > > >>>> > > > ---------------------------------------------------------------------- > > > > > >>>> 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 > > >>> > > >> > ---------------------------------------------------------------------- > > >> 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 > > >> -------------------------------------------------------- > > >> > > >> This message w/attachments (message) may be privileged, confidential > > >> or proprietary, and if you are not an intended recipient, please > > >> notify the sender, do not use or share it and delete it. Unless > > >> specifically indicated, this message is not an offer to sell or a > > >> solicitation of any investment products or other financial product > > >> or service, an official confirmation of any transaction, or an > > >> official statement of Merrill Lynch. Subject to applicable law, > > >> Merrill Lynch may monitor, review and retain e-communications (EC) > > >> traveling through its networks/systems. The laws of the country of > > >> each sender/recipient may impact the handling of EC, and EC may be > > >> archived, supervised and produced in countries other than the > > >> country in which you are located. This message cannot be guaranteed > > >> to be secure or error-free. This message is subject to terms > > >> available at the following link: > > >> > > > http://www.ml.com/e-communications_terms/ > > > > > >> . By messaging with Merrill Lynch you consent to the foregoing. > > >> -------------------------------------------------------- > > >> > > >> > ---------------------------------------------------------------------- > > >> 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 > > > > > > > > > > ---------------------------------------------------------------------- > > 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 > -------------------------------------------------------- > > This message w/attachments (message) may be privileged, confidential > or proprietary, and if you are not an intended recipient, please > notify the sender, do not use or share it and delete it. Unless > specifically indicated, this message is not an offer to sell or a > solicitation of any investment products or other financial product > or service, an official confirmation of any transaction, or an > official statement of Merrill Lynch. Subject to applicable law, > Merrill Lynch may monitor, review and retain e-communications (EC) > traveling through its networks/systems. The laws of the country of > each sender/recipient may impact the handling of EC, and EC may be > archived, supervised and produced in countries other than the > country in which you are located. This message cannot be guaranteed > to be secure or error-free. This message is subject to terms > available at the following link: http://www.ml.com/e-communications_terms/ > . By messaging with Merrill Lynch you consent to the foregoing. > -------------------------------------------------------- > > ---------------------------------------------------------------------- > 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
