[dm-devel] RE: Temporarily squelching multipathd errors

[Daniel Keisling]

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 at 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 at redhat.com 
> [mailto:dm-devel-bounces at redhat.com] On Behalf Of Domenico Viggiani
> Sent: Thursday, October 30, 2008 11:15 AM
> To: 'device-mapper development'
> Subject: [dm-devel] 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 at redhat.com
> 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.