* RE: Multipathing with RHEL4 U2 on EMC DMX
@ 2006-02-16 21:09 Child, David
2006-02-16 21:45 ` Bernd Zeimetz
0 siblings, 1 reply; 8+ messages in thread
From: Child, David @ 2006-02-16 21:09 UTC (permalink / raw)
To: dm-devel
Hello Brian,
Thanks for the tips. We aleady had the lvm.conf settings complete, but
your multipath.conf stanza for the Symmetrix was part of the solution.
Here is what I did to get it all working;
1. I found that the Symmetrix ID (serial number) for each LUN was
displaying FA port information instead of the common '000' digits (e.g.
790367051091 for LUN 051 on FA9, port 1). For multipath to work
correctly I would imagine that the C-bit setting (common serial number)
needed to be set on the Symmetrix FA port for that host. I checked with
the storage team and EMC PowerLink. We couldn't find any mention of
device-mapper, but PowerLink indicated that for Veritas DMP to work you
had to have the C-bit set so that was a fairly good confirmation. Once
the C-bit was set the serial numbers for both paths to a device came
back identical.
2. Added the SYMMETRIX device stanza listed in Brian's post to
/etc/multipath.conf;
devices {
device {
vendor "EMC "
product "SYMMETRIX "
getuid_callout "/sbin/scsi_id -g -u -s
/block/%n"
}
}
3. At this point auto-discovery of the paths worked, but my device files
were called things like: SEMC_____SYMMETRIX______790367051000. That
didn't look useful so I added the following to /etc/multipath.conf;
multipaths {
multipath {
wwid
SEMC_____SYMMETRIX______790367051000
alias sym051mp
}
<repeat for each LUN>
}
4. So far so good. I now had multipath devices in /dev/mpath called
"sym???mp". This will take care of the persistence issues, but it wasn't
picking up any partitions on those devices. I'm sure there is a better
way to fix it, but a quick hack I did took care of that.
a. I edited /etc/udev/rules.d/40-multipath.rules as follows;
KERNEL="dm-[0-9]*", PROGRAM="/sbin/dmsetup ls --target
linear --exec /usr/local/sbin/dmsetup_parser.sh -j %M -m %m",
RESULT="?*", NAME="%k", SYMLINK="mpath/%c"
(the original line used "--target multipath", but that
didn't pick up partitions. --target linear works, but picks up all kinds
of DM stuff (logical volumes, etc.). I therefore had to create a custom
parsing script.)
b. Created the dmsetup_parser.sh PROGRAM (as I said, its just a
quick hack and not optimized or anything);
#!/bin/bash
dev=`basename $*`
key=`echo $dev | cut -c 1-3`
if [ "${key}" = "sym" ]; then
echo "$dev"
fi
Now I have auto-detected multipaths for each EMC Symm LUN and each
partition on those LUNs (if any). The last item of importance (the most
important actually) is to figure out why both paths to a device get
knocked offline (failed) at the same time when hit with high I/O (see
original post).
Thanks,
David
David Child
Email David.Child@ps.net
-----Original Message-----
From: Brian Long <brilong cisco com>
To: device-mapper development <dm-devel redhat com>
Subject: Re: [dm-devel] Multipathing with RHEL4 U2 on EMC DMX
Date: Wed, 15 Feb 2006 14:52:12 -0500
On Fri, 2006-02-10 at 08:48 -0600, Child, David wrote:
> Hello,
>
> I've just recently connected some HP BL20p G3 blades running RHEL4 U2
> up to a DMX2000 (via McData switches). We didn't get PowerPath and
> intended to use device-mapper multipathing. I was able to get things
> up for the most part and get devices defined, but have to do that
> manually.
Hello David,
We have a /etc/lvm/lvm.conf and /etc/multipath.conf tweak you may be
interested in. I've attached them to this email.
/Brian/
^ permalink raw reply [flat|nested] 8+ messages in thread* RE: Multipathing with RHEL4 U2 on EMC DMX
@ 2006-02-16 22:05 egoggin
0 siblings, 0 replies; 8+ messages in thread
From: egoggin @ 2006-02-16 22:05 UTC (permalink / raw)
To: dm-devel
on Thursday, February 16, 2006 4:09 PM Child, David wrote:
> 3. At this point auto-discovery of the paths worked, but my
> device files
> were called things like: SEMC_____SYMMETRIX______790367051000. That
> didn't look useful so I added the following to /etc/multipath.conf;
> multipaths {
> multipath {
> wwid
> SEMC_____SYMMETRIX______790367051000
> alias sym051mp
> }
> <repeat for each LUN>
> }
The upstream version of scsi_id kept within udev is changed to support
retrieving a device UID from older model (4, 5, and 6) Symmetrix storage
arrays via the new scsi_id option "pre-spc3-83". Red Hat may have a version
of the udev RPM for update 2 with this change.
Setting up the Symmetrix device entry in /etc/multipath.conf to also use
this option "-ppre-spc3-83" will cause dm multipath to generate mapped
device names for Symmetrix logical units which do not have the vendor/model
prefix.
Both of these changes are in SuSE SLES 9 SP3 and it works as stated above.
^ permalink raw reply [flat|nested] 8+ messages in thread* RE: Multipathing with RHEL4 U2 on EMC DMX
@ 2006-02-13 16:53 Child, David
0 siblings, 0 replies; 8+ messages in thread
From: Child, David @ 2006-02-13 16:53 UTC (permalink / raw)
To: dm-devel
A quick update; I noticed that the string I was using to create the
multipath device was actually for a failover setup, not multibus. I had
been using:
# echo "0 141419520 multipath 0 0 2 1 round-robin 0 1 1 8:48 1000
round-robin 0 1 1 8:176 1000" | dmsetup create dm2
From what I can see on Christophe's wiki it should have been the
following to get a multibus configuration:
# echo "0 141419520 multipath 0 0 1 1 round-robin 0 2 1 8:48 1000
8:176 1000" | dmsetup create dm2
The output of 'multipath -l' for this device now appears as;
dm2 ()
[size=67 GB][features="0"][hwhandler="0"]
\_ round-robin 0 [enabled]
\_ 0:0:0:6 sdd 8:48 [active][ready]
\_ 1:0:0:6 sdl 8:176 [active][ready]
I'm not sure if this will fix any of my issues (primarily the LUN
dropping off), but wanted to send in this update since my original post
had mentioned that I had been thinking about using "failover" instead of
"multibus". In reality I was using "failover". I'll see how it goes with
my multibus setup, but I'm still curious how you get the settings in
/etc/multipath to work. I tried changing the values under the "defaults"
section for 'scsi_id' as seen below, but it still keeps using the same
command as before.
Update: Setting this device for 'multibus' (as listed above) seemed to
make matters worse. Quickly after running any I/O over the multipath
device knocked it offline. I put it back to my original setup (using the
first string I listed) and was able to write quite a bit of data to the
device before it was knocked offline.
Thanks,
David
David Child
Email David.Child@ps.net
_____________________________________________
From: Child, David
Sent: Friday, February 10, 2006 8:48 AM
To: 'dm-devel@redhat.com'
Subject: [dm-devel] Multipathing with RHEL4 U2 on EMC DMX
Hello,
I've just recently connected some HP BL20p G3 blades running RHEL4 U2 up
to a DMX2000 (via McData switches). We didn't get PowerPath and intended
to use device-mapper multipathing. I was able to get things up for the
most part and get devices defined, but have to do that manually. I've
run into a few issues/concerns that I was hoping someone had run across;
Kernel: 2.6.9-22.Elsmp
Multipath tools: multipath-tools-0.4.6.1-1
Device Mapper: device-mapper-1.01.05-01
1. When running 'multipath -v3' I get errors from the getuid_callout
string; "error calling out scsi_id -g -ppre-spc3-83 -u -s /block/sdb".
It doesn't like the "-ppre-spc3-83" part. After some research it appears
that for the DMX (Symmetrix) a more appropriate string would be
"/sbin/scsi_id -g -p 0x80 -u -s /block/sdb". I tried adding that into
the 'defaults' section of /etc/multipath.conf, but it doesn't appear to
pick it up. I've tried restarting multipathd, rebooting, etc. Is there
anyway to get it to take this string? I believe that is part of the
problem I'm having with the next item (#2).
2. In order to have multipath working for my EMC devices I have to
manually create them on system reboot. I simply created a new startup
script for this. Basically I just do; 'echo "0 17677440 multipath 0 0 2
1 round-robin 0 1 1 8:112 1000 round-robin 0 1 1 8:240 1000" | dmsetup
create dm0' for each device. Is that normal to have to do that or is
there a way to do this automatically? I would suspect it has to do with
having a hardware_handler. I thought about the dm-emc handler, but that
appears to only work for the CX/AX/FC family (i.e. Clariion) of arrays
which work nothing like the Symmetrix. Perhaps if I could get the
getuid_callout string working that would help.
3. Early this morning there was a problem on one of the multipath
devices used for Oracle ASM;
SCSI error : <0 0 0 6> return code = 0x20000
end_request: I/O error, dev sdd, sector 64078960
end_request: I/O error, dev sdd, sector 64078961
device-mapper: dm-multipath: Failing path 8:48.
SCSI error : <1 0 0 6> return code = 0x20000
end_request: I/O error, dev sdl, sector 34888112
end_request: I/O error, dev sdl, sector 34888113
device-mapper: dm-multipath: Failing path 8:176.
'multipath -l' showed the device as;
dm2 ()
[size=67 GB][features="0"][hwhandler="0"]
\_ round-robin 0 [enabled]
\_ 0:0:0:6 sdd 8:48 [failed][ready]
\_ round-robin 0 [enabled]
\_ 1:0:0:6 sdl 8:176 [failed][ready]
The LUNs on this server are shared between three servers and the other
two remained on-line so I know the LUN or paths to the array didn't go
out. Since the other LUNs on this server remained active I know I didn't
loose any HBA connectivity either. The DBAs said they were writing a
bunch of data to it when it dropped off line. I ran a few 'multipath'
and 'dmsetup status' commands to see what was up and it came back online
(it had been "failed" from ~3am to 7am).
Should I try using "failover" instead of "multibus" for my
"path_grouping_policy"? I would like to have it load balance, but
failover is more important.
Sorry for the long-winded post.
Any help would be appreciated.
Thanks,
David
David Child
Email David.Child@ps.net.
^ permalink raw reply [flat|nested] 8+ messages in thread* RE: Multipathing with RHEL4 U2 on EMC DMX
@ 2006-02-10 21:39 Child, David
0 siblings, 0 replies; 8+ messages in thread
From: Child, David @ 2006-02-10 21:39 UTC (permalink / raw)
To: dm-devel
[-- Attachment #1.1: Type: text/plain, Size: 4984 bytes --]
A quick update; I noticed that the string I was using to create the
multipath device was actually for a failover setup, not multibus. I had
been using:
# echo "0 141419520 multipath 0 0 2 1 round-robin 0 1 1 8:48 1000
round-robin 0 1 1 8:176 1000" | dmsetup create dm2
From what I can see on Christophe's wiki it should have been the
following to get a multibus configuration:
# echo "0 141419520 multipath 0 0 1 1 round-robin 0 2 1 8:48 1000
8:176 1000" | dmsetup create dm2
The output of 'multipath -l' for this device now appears as;
dm2 ()
[size=67 GB][features="0"][hwhandler="0"]
\_ round-robin 0 [enabled]
\_ 0:0:0:6 sdd 8:48 [active][ready]
\_ 1:0:0:6 sdl 8:176 [active][ready]
I'm not sure if this will fix any of my issues (primarily the LUN
dropping off), but wanted to send in this update since my original post
had mentioned that I had been thinking about using "failover" instead of
"multibus". In reality I was using "failover". I'll see how it goes with
my multibus setup, but I'm still curious how you get the settings in
/etc/multipath to work. I tried changing the values under the "defaults"
section for 'scsi_id' as seen below, but it still keeps using the same
command as before.
Thanks,
David
David Child
Email David.Child@ps.net
> _____________________________________________
> From: Child, David
> Sent: Friday, February 10, 2006 8:48 AM
> To: 'dm-devel@redhat.com'
> Subject: [dm-devel] Multipathing with RHEL4 U2 on EMC DMX
>
> Hello,
>
> I've just recently connected some HP BL20p G3 blades running RHEL4 U2
> up to a DMX2000 (via McData switches). We didn't get PowerPath and
> intended to use device-mapper multipathing. I was able to get things
> up for the most part and get devices defined, but have to do that
> manually. I've run into a few issues/concerns that I was hoping
> someone had run across;
>
> Kernel: 2.6.9-22.Elsmp
> Multipath tools: multipath-tools-0.4.6.1-1
> Device Mapper: device-mapper-1.01.05-01
>
> 1. When running 'multipath -v3' I get errors from the getuid_callout
> string; "error calling out scsi_id -g -ppre-spc3-83 -u -s /block/sdb".
> It doesn't like the "-ppre-spc3-83" part. After some research it
> appears that for the DMX (Symmetrix) a more appropriate string would
> be "/sbin/scsi_id -g -p 0x80 -u -s /block/sdb". I tried adding that
> into the 'defaults' section of /etc/multipath.conf, but it doesn't
> appear to pick it up. I've tried restarting multipathd, rebooting,
> etc. Is there anyway to get it to take this string? I believe that is
> part of the problem I'm having with the next item (#2).
>
> 2. In order to have multipath working for my EMC devices I have to
> manually create them on system reboot. I simply created a new startup
> script for this. Basically I just do; 'echo "0 17677440 multipath 0 0
> 2 1 round-robin 0 1 1 8:112 1000 round-robin 0 1 1 8:240 1000" |
> dmsetup create dm0' for each device. Is that normal to have to do that
> or is there a way to do this automatically? I would suspect it has to
> do with having a hardware_handler. I thought about the dm-emc handler,
> but that appears to only work for the CX/AX/FC family (i.e. Clariion)
> of arrays which work nothing like the Symmetrix. Perhaps if I could
> get the getuid_callout string working that would help.
>
> 3. Early this morning there was a problem on one of the multipath
> devices used for Oracle ASM;
>
> SCSI error : <0 0 0 6> return code = 0x20000
> end_request: I/O error, dev sdd, sector 64078960
> end_request: I/O error, dev sdd, sector 64078961
> device-mapper: dm-multipath: Failing path 8:48.
> SCSI error : <1 0 0 6> return code = 0x20000
> end_request: I/O error, dev sdl, sector 34888112
> end_request: I/O error, dev sdl, sector 34888113
> device-mapper: dm-multipath: Failing path 8:176.
>
> 'multipath -l' showed the device as;
>
> dm2 ()
> [size=67 GB][features="0"][hwhandler="0"]
> \_ round-robin 0 [enabled]
> \_ 0:0:0:6 sdd 8:48 [failed][ready]
> \_ round-robin 0 [enabled]
> \_ 1:0:0:6 sdl 8:176 [failed][ready]
>
> The LUNs on this server are shared between three servers and the other
> two remained on-line so I know the LUN or paths to the array didn't go
> out. Since the other LUNs on this server remained active I know I
> didn't loose any HBA connectivity either. The DBAs said they were
> writing a bunch of data to it when it dropped off line. I ran a few
> 'multipath' and 'dmsetup status' commands to see what was up and it
> came back online (it had been "failed" from ~3am to 7am).
>
> Should I try using "failover" instead of "multibus" for my
> "path_grouping_policy"? I would like to have it load balance, but
> failover is more important.
>
> Sorry for the long-winded post.
>
> Any help would be appreciated.
>
> Thanks,
> David
>
> David Child
> Email David.Child@ps.net.
>
[-- Attachment #1.2: Type: text/html, Size: 9056 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread* Multipathing with RHEL4 U2 on EMC DMX
@ 2006-02-10 14:48 Child, David
2006-02-15 19:52 ` Brian Long
2006-02-16 21:37 ` Bernd Zeimetz
0 siblings, 2 replies; 8+ messages in thread
From: Child, David @ 2006-02-10 14:48 UTC (permalink / raw)
To: dm-devel
[-- Attachment #1.1: Type: text/plain, Size: 3290 bytes --]
Hello,
I've just recently connected some HP BL20p G3 blades running RHEL4 U2 up
to a DMX2000 (via McData switches). We didn't get PowerPath and intended
to use device-mapper multipathing. I was able to get things up for the
most part and get devices defined, but have to do that manually. I've
run into a few issues/concerns that I was hoping someone had run across;
Kernel: 2.6.9-22.Elsmp
Multipath tools: multipath-tools-0.4.6.1-1
Device Mapper: device-mapper-1.01.05-01
1. When running 'multipath -v3' I get errors from the getuid_callout
string; "error calling out scsi_id -g -ppre-spc3-83 -u -s /block/sdb".
It doesn't like the "-ppre-spc3-83" part. After some research it appears
that for the DMX (Symmetrix) a more appropriate string would be
"/sbin/scsi_id -g -p 0x80 -u -s /block/sdb". I tried adding that into
the 'defaults' section of /etc/multipath.conf, but it doesn't appear to
pick it up. I've tried restarting multipathd, rebooting, etc. Is there
anyway to get it to take this string? I believe that is part of the
problem I'm having with the next item (#2).
2. In order to have multipath working for my EMC devices I have to
manually create them on system reboot. I simply created a new startup
script for this. Basically I just do; 'echo "0 17677440 multipath 0 0 2
1 round-robin 0 1 1 8:112 1000 round-robin 0 1 1 8:240 1000" | dmsetup
create dm0' for each device. Is that normal to have to do that or is
there a way to do this automatically? I would suspect it has to do with
having a hardware_handler. I thought about the dm-emc handler, but that
appears to only work for the CX/AX/FC family (i.e. Clariion) of arrays
which work nothing like the Symmetrix. Perhaps if I could get the
getuid_callout string working that would help.
3. Early this morning there was a problem on one of the multipath
devices used for Oracle ASM;
SCSI error : <0 0 0 6> return code = 0x20000
end_request: I/O error, dev sdd, sector 64078960
end_request: I/O error, dev sdd, sector 64078961
device-mapper: dm-multipath: Failing path 8:48.
SCSI error : <1 0 0 6> return code = 0x20000
end_request: I/O error, dev sdl, sector 34888112
end_request: I/O error, dev sdl, sector 34888113
device-mapper: dm-multipath: Failing path 8:176.
'multipath -l' showed the device as;
dm2 ()
[size=67 GB][features="0"][hwhandler="0"]
\_ round-robin 0 [enabled]
\_ 0:0:0:6 sdd 8:48 [failed][ready]
\_ round-robin 0 [enabled]
\_ 1:0:0:6 sdl 8:176 [failed][ready]
The LUNs on this server are shared between three servers and the other
two remained on-line so I know the LUN or paths to the array didn't go
out. Since the other LUNs on this server remained active I know I didn't
loose any HBA connectivity either. The DBAs said they were writing a
bunch of data to it when it dropped off line. I ran a few 'multipath'
and 'dmsetup status' commands to see what was up and it came back online
(it had been "failed" from ~3am to 7am).
Should I try using "failover" instead of "multibus" for my
"path_grouping_policy"? I would like to have it load balance, but
failover is more important.
Sorry for the long-winded post.
Any help would be appreciated.
Thanks,
David
David Child
Email David.Child@ps.net.
[-- Attachment #1.2: Type: text/html, Size: 5890 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Multipathing with RHEL4 U2 on EMC DMX
2006-02-10 14:48 Child, David
@ 2006-02-15 19:52 ` Brian Long
2006-02-16 21:37 ` Bernd Zeimetz
1 sibling, 0 replies; 8+ messages in thread
From: Brian Long @ 2006-02-15 19:52 UTC (permalink / raw)
To: device-mapper development
[-- Attachment #1: Type: text/plain, Size: 774 bytes --]
On Fri, 2006-02-10 at 08:48 -0600, Child, David wrote:
> Hello,
>
> I've just recently connected some HP BL20p G3 blades running RHEL4 U2
> up to a DMX2000 (via McData switches). We didn't get PowerPath and
> intended to use device-mapper multipathing. I was able to get things
> up for the most part and get devices defined, but have to do that
> manually.
Hello David,
We have a /etc/lvm/lvm.conf and /etc/multipath.conf tweak you may be
interested in. I've attached them to this email.
/Brian/
--
Brian Long | | |
IT Data Center Systems | .|||. .|||.
Cisco Linux Developer | ..:|||||||:...:|||||||:..
Phone: (919) 392-7363 | C i s c o S y s t e m s
[-- Attachment #2: lvm.conf.cisco --]
[-- Type: text/plain, Size: 10376 bytes --]
# Refer to 'man lvm.conf' for further information including the file layout.
#
# To put this file in a different directory and override /etc/lvm set
# the environment variable LVM_SYSTEM_DIR before running the tools.
# This section allows you to configure which block devices should
# be used by the LVM system.
devices {
# Where do you want your volume groups to appear ?
dir = "/dev"
# An array of directories that contain the device nodes you wish
# to use with LVM2.
scan = [ "/dev" ]
# A filter that tells LVM2 to only use a restricted set of devices.
# The filter consists of an array of regular expressions. These
# expressions can be delimited by a character of your choice, and
# prefixed with either an 'a' (for accept) or 'r' (for reject).
# The first expression found to match a device name determines if
# the device will be accepted or rejected (ignored). Devices that
# don't match any patterns are accepted.
# Be careful if there there are symbolic links or multiple filesystem
# entries for the same device as each name is checked separately against
# the list of patterns. The effect is that if any name matches any 'a'
# pattern, the device is accepted; otherwise if any name matches any 'r'
# pattern it is rejected; otherwise it is accepted.
# Remember to run vgscan after you change this parameter to ensure
# that the cache file gets regenerated (see below).
# By default we accept every block device:
# filter = [ "a/.*/" ]
# Cisco filter
filter = [ "a|^/dev/mapper/.*|", "r/.*/" ]
# Exclude the cdrom drive
# filter = [ "r|/dev/cdrom|" ]
# When testing I like to work with just loopback devices:
#filter = [ "a|loop|", "r/.*/" ]
# Or maybe all loops and ide drives except hdc:
# filter =[ "a|loop|", "r|/dev/hdc|", "a|/dev/ide|", "r|.*|" ]
# Use anchors if you want to be really specific
# filter = [ "a|^/dev/hda8$|", "r/.*/" ]
# The results of the filtering are cached on disk to avoid
# rescanning dud devices (which can take a very long time). By
# default this cache file is hidden in the /etc/lvm directory.
# It is safe to delete this file: the tools regenerate it.
cache = "/etc/lvm/.cache"
# You can turn off writing this cache file by setting this to 0.
write_cache_state = 1
# Advanced settings.
# List of pairs of additional acceptable block device types found
# in /proc/devices with maximum (non-zero) number of partitions.
# types = [ "fd", 16 ]
# Cisco added
types = [ "device-mapper", 1 ]
# If sysfs is mounted (2.6 kernels) restrict device scanning to
# the block devices it believes are valid.
# 1 enables; 0 disables.
sysfs_scan = 1
# By default, LVM2 will ignore devices used as components of
# software RAID (md) devices by looking for md superblocks.
# 1 enables; 0 disables.
# Cisco changed
md_component_detection = 0
}
# This section that allows you to configure the nature of the
# information that LVM2 reports.
log {
# Controls the messages sent to stdout or stderr.
# There are three levels of verbosity, 3 being the most verbose.
verbose = 0
# Should we send log messages through syslog?
# 1 is yes; 0 is no.
syslog = 1
# Should we log error and debug messages to a file?
# By default there is no log file.
#file = "/var/log/lvm2.log"
# Should we overwrite the log file each time the program is run?
# By default we append.
overwrite = 0
# What level of log messages should we send to the log file and/or syslog?
# There are 6 syslog-like log levels currently in use - 2 to 7 inclusive.
# 7 is the most verbose (LOG_DEBUG).
level = 0
# Format of output messages
# Whether or not (1 or 0) to indent messages according to their severity
indent = 1
# Whether or not (1 or 0) to display the command name on each line output
command_names = 0
# A prefix to use before the message text (but after the command name,
# if selected). Default is two spaces, so you can see/grep the severity
# of each message.
prefix = " "
# To make the messages look similar to the original LVM tools use:
# indent = 0
# command_names = 1
# prefix = " -- "
# Set this if you want log messages during activation.
# Don't use this in low memory situations (can deadlock).
# activation = 0
}
# Configuration of metadata backups and archiving. In LVM2 when we
# talk about a 'backup' we mean making a copy of the metadata for the
# *current* system. The 'archive' contains old metadata configurations.
# Backups are stored in a human readeable text format.
backup {
# Should we maintain a backup of the current metadata configuration ?
# Use 1 for Yes; 0 for No.
# Think very hard before turning this off!
backup = 1
# Where shall we keep it ?
# Remember to back up this directory regularly!
backup_dir = "/etc/lvm/backup"
# Should we maintain an archive of old metadata configurations.
# Use 1 for Yes; 0 for No.
# On by default. Think very hard before turning this off.
archive = 1
# Where should archived files go ?
# Remember to back up this directory regularly!
archive_dir = "/etc/lvm/archive"
# What is the minimum number of archive files you wish to keep ?
retain_min = 10
# What is the minimum time you wish to keep an archive file for ?
retain_days = 30
}
# Settings for the running LVM2 in shell (readline) mode.
shell {
# Number of lines of history to store in ~/.lvm_history
history_size = 100
}
# Miscellaneous global LVM2 settings
global {
# The file creation mask for any files and directories created.
# Interpreted as octal if the first digit is zero.
umask = 077
# Allow other users to read the files
#umask = 022
# Enabling test mode means that no changes to the on disk metadata
# will be made. Equivalent to having the -t option on every
# command. Defaults to off.
test = 0
# Whether or not to communicate with the kernel device-mapper.
# Set to 0 if you want to use the tools to manipulate LVM metadata
# without activating any logical volumes.
# If the device-mapper kernel driver is not present in your kernel
# setting this to 0 should suppress the error messages.
activation = 1
# If we can't communicate with device-mapper, should we try running
# the LVM1 tools?
# This option only applies to 2.4 kernels and is provided to help you
# switch between device-mapper kernels and LVM1 kernels.
# The LVM1 tools need to be installed with .lvm1 suffices
# e.g. vgscan.lvm1 and they will stop working after you start using
# the new lvm2 on-disk metadata format.
# The default value is set when the tools are built.
# fallback_to_lvm1 = 0
# The default metadata format that commands should use - "lvm1" or "lvm2".
# The command line override is -M1 or -M2.
# Defaults to "lvm1" if compiled in, else "lvm2".
# format = "lvm1"
# Location of proc filesystem
proc = "/proc"
# Type of locking to use. Defaults to file-based locking (1).
# Turn locking off by setting to 0 (dangerous: risks metadata corruption
# if LVM2 commands get run concurrently).
locking_type = 1
# Local non-LV directory that holds file-based locks while commands are
# in progress. A directory like /tmp that may get wiped on reboot is OK.
locking_dir = "/var/lock/lvm"
# Other entries can go here to allow you to load shared libraries
# e.g. if support for LVM1 metadata was compiled as a shared library use
# format_libraries = "liblvm2format1.so"
# Full pathnames can be given.
# Search this directory first for shared libraries.
# library_dir = "/lib"
}
activation {
# Device used in place of missing stripes if activating incomplete volume.
# For now, you need to set this up yourself first (e.g. with 'dmsetup')
# For example, you could make it return I/O errors using the 'error'
# target or make it return zeros.
missing_stripe_filler = "/dev/ioerror"
# Size (in KB) of each copy operation when mirroring
mirror_region_size = 512
# How much stack (in KB) to reserve for use while devices suspended
reserved_stack = 256
# How much memory (in KB) to reserve for use while devices suspended
reserved_memory = 8192
# Nice value used while devices suspended
process_priority = -18
# If volume_list is defined, each LV is only activated if there is a
# match against the list.
# "vgname" and "vgname/lvname" are matched exactly.
# "@tag" matches any tag set in the LV or VG.
# "@*" matches if any tag defined on the host is also set in the LV or VG
#
# volume_list = [ "vg1", "vg2/lvol1", "@tag1", "@*" ]
}
####################
# Advanced section #
####################
# Metadata settings
#
# metadata {
# Default number of copies of metadata to hold on each PV. 0, 1 or 2.
# You might want to override it from the command line with 0
# when running pvcreate on new PVs which are to be added to large VGs.
# pvmetadatacopies = 1
# Approximate default size of on-disk metadata areas in sectors.
# You should increase this if you have large volume groups or
# you want to retain a large on-disk history of your metadata changes.
# pvmetadatasize = 255
# List of directories holding live copies of text format metadata.
# These directories must not be on logical volumes!
# It's possible to use LVM2 with a couple of directories here,
# preferably on different (non-LV) filesystems, and with no other
# on-disk metadata (pvmetadatacopies = 0). Or this can be in
# addition to on-disk metadata areas.
# The feature was originally added to simplify testing and is not
# supported under low memory situations - the machine could lock up.
#
# Never edit any files in these directories by hand unless you
# you are absolutely sure you know what you are doing! Use
# the supplied toolset to make changes (e.g. vgcfgrestore).
# dirs = [ "/etc/lvm/metadata", "/mnt/disk2/lvm/metadata2" ]
#}
[-- Attachment #3: multipath.conf.cisco --]
[-- Type: text/plain, Size: 1690 bytes --]
# See /usr/share/doc/device-mapper-multipath-*/multipath.conf.annotated
# for a fully-detailed multipath.conf.
#
# BEGIN Cisco-specific configuration
defaults {
multipath_tool "/sbin/multipath -v0"
udev_dir /dev
polling_interval 10
default_selector "round-robin 0"
default_path_grouping_policy multibus
default_getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
default_prio_callout "/bin/true"
default_features "0"
rr_wmin_io 100
failback immediate
}
# Only specify options in the devices section to override the defaults.
devices {
# EMC Symmetrix / DMX
device {
vendor "EMC "
product "SYMMETRIX "
}
# EMC Clariion (active/passive)
device {
vendor "DGC "
product "RAID 5 "
path_grouping_policy failover
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
path_checker emc_clariion
path_selector "round-robin 0"
features "0"
hardware_handler "1 emc"
failback immediate
}
device {
vendor "DGC "
product " "
path_grouping_policy failover
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
path_checker emc_clariion
path_selector "round-robin 0"
features "0"
hardware_handler "1 emc"
failback immediate
}
}
# END Cisco-specific configuration
[-- Attachment #4: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Multipathing with RHEL4 U2 on EMC DMX
2006-02-10 14:48 Child, David
2006-02-15 19:52 ` Brian Long
@ 2006-02-16 21:37 ` Bernd Zeimetz
1 sibling, 0 replies; 8+ messages in thread
From: Bernd Zeimetz @ 2006-02-16 21:37 UTC (permalink / raw)
To: device-mapper development
Hi,
> SCSI error : <0 0 0 6> return code = 0x20000
> end_request: I/O error, dev sdd, sector 64078960
> end_request: I/O error, dev sdd, sector 64078961
> device-mapper: dm-multipath: Failing path 8:48.
> SCSI error : <1 0 0 6> return code = 0x20000
> end_request: I/O error, dev sdl, sector 34888112
> end_request: I/O error, dev sdl, sector 34888113
> device-mapper: dm-multipath: Failing path 8:176.
>
we had this problem with our buggy CX here, too. I thought that the CX
had some issues, but now I start to think that's a fault on the kernel side.
If anybody is interested - as the buggy CX will be replaced, we're
moving our production data to a different storage until we have the new
machine. The old one will be used as additional disk-to-disk backup, but
I can't see there any problems in testing/debugging stuff with it. At
least I can put it under heavy load and see what will happen.
Any ideas on that?
Best regards,
Bernd Zeimetz
Darmstadt University of Technology
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2006-02-16 22:05 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-16 21:09 Multipathing with RHEL4 U2 on EMC DMX Child, David
2006-02-16 21:45 ` Bernd Zeimetz
-- strict thread matches above, loose matches on Subject: below --
2006-02-16 22:05 egoggin
2006-02-13 16:53 Child, David
2006-02-10 21:39 Child, David
2006-02-10 14:48 Child, David
2006-02-15 19:52 ` Brian Long
2006-02-16 21:37 ` Bernd Zeimetz
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.