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
