I was able to get this working once I upgraded to
device-mapper-multipath-0.4.5-21.RHEL4. I did have to make a
modification to my multipath.conf, this was due to the behavior of
dasdview in RHEL 4. My version of s390utils is, s390utils-1.3.2-2.40.12.
Applying the following patch resolved the issue associated with dasdview.
28c28
< getuid_callout "/sbin/dasdview -j /dev/%n"
---
> getuid_callout "/sbin/dasdview -j -f /dev/%n"
Once applied and multipath was active I actually performance
improvements of almost 50%, i.e. what took 44s to complete only took 26s.
The following document was a huge help.
http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/docu/l26chp01.pdf
Thank you all who assisted...
Stefan Bader wrote:
Can you post "multipath -v6" output for it?
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:56:43:
Testing with
device-mapper-multipath-0.4.5-21.RHEL4-s390x
and making much more progress. Still not getting any output from
multipath -ll...
Stefan Bader wrote:
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
----------------------------------------------------------------------
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
