I am still getting multipath errors when unpresenting and presenting
LUNs. I've traced it down to getting path failures everytime I either
remove or add a LUN to the system. The strange thing is that I get path
errors for maps that aren't related to the LUNs I am deleting or adding.
In this case, I am deleting the LUN with the map 'mpath18,' but other
maps complain whenever the LUN is deleted:
Nov 21 13:47:05 ausracdbd01 multipathd: checker failed path 67:208 in
map orabackup_hs
Nov 21 13:47:05 ausracdbd01 kernel: device-mapper: multipath: Failing
path 67:208.
Nov 21 13:47:08 ausracdbd01 multipathd: checker failed path 70:160 in
map mpath18
Nov 21 13:47:08 ausracdbd01 kernel: device-mapper: multipath: Failing
path 70:160.
Nov 21 13:47:09 ausracdbd01 multipathd: checker failed path 69:0 in map
orabackup_hs
Nov 21 13:47:09 ausracdbd01 kernel: device-mapper: multipath: Failing
path 69:0.
Nov 21 13:47:10 ausracdbd01 multipathd: checker failed path 65:192 in
map ph1d
Nov 21 13:47:10 ausracdbd01 kernel: device-mapper: multipath: Failing
path 65:192.
Nov 21 13:47:10 ausracdbd01 multipathd: checker failed path 65:224 in
map limsd
Nov 21 13:47:10 ausracdbd01 kernel: device-mapper: multipath: Failing
path 65:224.
Nov 21 13:47:10 ausracdbd01 multipathd: checker failed path 65:240 in
map limsd_arch
Sometimes I only get 5-10 "checker failed path" errors, other times I
get 30+.
Can anyone give me any advice? These are OCFS2 filesystems on RHEL5
attached to a HP EVA8000.
[root@ausracdbd01 ~]# rpm -qa | grep mapper
device-mapper-1.02.20-1.el5
device-mapper-1.02.20-1.el5
device-mapper-multipath-0.4.7-12.el5
Relevant /etc/multipath.conf entries:
### HP Storageworks Arrays.
defaults {
udev_dir /dev
polling_interval 10
selector "round-robin 0"
path_grouping_policy failover
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
prio_callout "/bin/true"
path_checker tur
rr_min_io 100
rr_weight uniform
failback immediate
no_path_retry 12
user_friendly_names yes
bindings_file "/var/lib/multipath/bindings"
devices {
# For EVA3000(HSV101) / EVA5000(HSV111) / EVA4000/6000 / EVA8000
device {
vendor "HP|COMPAQ"
product "HSV1[01]1 \(C\)COMPAQ|HSV[23][01]0"
path_grouping_policy group_by_prio
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
path_checker tur
path_selector "round-robin 0"
prio_callout "/sbin/mpath_prio_alua /dev/%n"
rr_weight uniform
failback immediate
hardware_handler "0"
no_path_retry 12
}
TIA,
Daniel
> -----Original Message-----
> From: dm-devel-bounces@xxxxxxxxxx
> [mailto:dm-devel-bounces@xxxxxxxxxx] On Behalf Of Domenico Viggiani
> Sent: Thursday, October 30, 2008 11:15 AM
> To: 'device-mapper development'
> Subject: RE: Temporarily squelching multipathd errors
>
> > From Daniel Keisling:
> >
> > What is proper procedure to completely remove all SCSI
> > devices and multipath maps so that multipathd will not
> > generate error messages when the LUN is unpresented from the system?
>
> This is my recipe:
>
> - Take a note of "multipath -ll" output (SCSI-IDs, long multipath
> identifiers, etc)
> - Umount filesystem
> - Deactivate VG
> vgchange -an vg_XXX
> - Export VG
> vgexport vg_XXX
> - Remove multipath
> multipath -f <long-multipath-identifier>
> - Unpresent/destroy array LUN
> - Remove SCSI devices
> echo 1 > /sys/bus/scsi/drivers/sd/<SCSI-ID>/delete
> ... (for all paths)
> - Edit fstab
>
>
> --
> Domenico Viggiani
>
> --
> dm-devel mailing list
> dm-devel@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/dm-devel
>
>
______________________________________________________________________
This email transmission and any documents, files or previous email
messages attached to it may contain information that is confidential or
legally privileged. If you are not the intended recipient or a person
responsible for delivering this transmission to the intended recipient,
you are hereby notified that you must not read this transmission and
that any disclosure, copying, printing, distribution or use of this
transmission is strictly prohibited. If you have received this transmission
in error, please immediately notify the sender by telephone or return email
and delete the original transmission and its attachments without reading
or saving in any manner.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
