<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<META content="MSHTML 6.00.2900.2802" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>The mpath_prio_emc with group_by_prio did the
trick. Thanks!</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>But I am still loosing the paths to the failed
devices. </FONT><FONT face=Arial size=2>I Increased dev_loss_tmo, but the
maximum seems to be about 600 - thus, after 10 Minutes, the paths
fail:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>SANfile_m linux # multipath -l<BR>hcfshare
(360060160c820080063502869e459dc11) dm-0 ,<BR>[size=3.4T][features=1
queue_if_no_path][hwhandler=1 emc]<BR>\_ round-robin 0
[prio=0][enabled]<BR> \_ #:#:#:# - #:#
[failed][undef]<BR> \_ #:#:#:# - #:#
[failed][undef]<BR>\_ round-robin 0 [prio=0][active]<BR> \_ 2:0:0:0 sdd
8:48 [active][undef]<BR> \_ 1:0:0:0 sdb 8:16
[active][undef]<BR></FONT></DIV>
<DIV><FONT face=Arial size=2>If I put them online again, I run
into the -EEXIST prob. Async SCSI scanning *is* off in my kernel,
so the only thing I could do from here is to try the patch, is
it?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Oct 17 17:26:34 SANfile_m kernel: scsi 1:0:1:0:
rejecting I/O to dead device<BR>Oct 17 17:26:34 SANfile_m multipathd: sdc:
emc_clariion_checker: query command indicates error<BR>Oct 17 17:26:35 SANfile_m
kernel: scsi 2:0:1:0: rejecting I/O to dead device<BR>Oct 17 17:26:35 SANfile_m
multipathd: sde: emc_clariion_checker: query command indicates error<BR>Oct 17
17:26:36 SANfile_m kernel: scsi 1:0:1:0: Direct-Access
DGC RAID
5 0219 PQ: 0 ANSI:
4<BR>Oct 17 17:26:36 SANfile_m kernel: sd 1:0:1:0: [sdf] Very big device. Trying
to use READ CAPACITY(16).<BR>Oct 17 17:26:36 SANfile_m kernel: sd 1:0:1:0: [sdf]
7263453184 512-byte hardware sectors (3718888 MB)<BR>Oct 17 17:26:36 SANfile_m
kernel: sd 1:0:1:0: [sdf] Test WP failed, assume Write Enabled<BR>Oct 17
17:26:36 SANfile_m kernel: sd 1:0:1:0: [sdf] Asking for cache data failed<BR>Oct
17 17:26:36 SANfile_m kernel: sd 1:0:1:0: [sdf] Assuming drive cache: write
through<BR>Oct 17 17:26:36 SANfile_m kernel: sd 1:0:1:0: [sdf] Very big device.
Trying to use READ CAPACITY(16).<BR>Oct 17 17:26:36 SANfile_m kernel: sd
1:0:1:0: [sdf] 7263453184 512-byte hardware sectors (3718888 MB)<BR>Oct 17
17:26:36 SANfile_m kernel: sd 1:0:1:0: [sdf] Test WP failed, assume Write
Enabled<BR>Oct 17 17:26:36 SANfile_m kernel: sd 1:0:1:0: [sdf] Asking for cache
data failed<BR>Oct 17 17:26:36 SANfile_m kernel: sd 1:0:1:0: [sdf] Assuming
drive cache: write through<BR>Oct 17 17:26:36 SANfile_m kernel:
sdf:<6>sd 1:0:1:0: [sdf] Device not ready: <6>: Sense Key : 0x2
[current]<BR>Oct 17 17:26:36 SANfile_m kernel: : ASC=0x4 ASCQ=0x3<BR>Oct 17
17:26:36 SANfile_m kernel: end_request: I/O error, dev sdf, sector 0<BR>Oct 17
17:26:36 SANfile_m kernel: printk: 40 messages suppressed.<BR>Oct 17 17:26:36
SANfile_m kernel: Buffer I/O error on device sdf, logical block 0<BR>Oct 17
17:26:36 SANfile_m kernel: sd 1:0:1:0: [sdf] Device not ready: <6>: Sense
Key : 0x2 [current]<BR>Oct 17 17:26:36 SANfile_m kernel: : ASC=0x4
ASCQ=0x3<BR>Oct 17 17:26:36 SANfile_m kernel: end_request: I/O error, dev sdf,
sector 0<BR>Oct 17 17:26:36 SANfile_m kernel: Buffer I/O error on device sdf,
logical block 0<BR>Oct 17 17:26:36 SANfile_m kernel: sd 1:0:1:0: [sdf] Device
not ready: <6>: Sense Key : 0x2 [current]<BR>Oct 17 17:26:36 SANfile_m
kernel: : ASC=0x4 ASCQ=0x3<BR>Oct 17 17:26:36 SANfile_m kernel: end_request: I/O
error, dev sdf, sector 0<BR>Oct 17 17:26:36 SANfile_m kernel: Buffer I/O error
on device sdf, logical block 0<BR>Oct 17 17:26:36 SANfile_m kernel:
ldm_validate_partition_table(): Disk read failed.<BR>Oct 17 17:26:36 SANfile_m
kernel: sd 1:0:1:0: [sdf] Device not ready: <6>: Sense Key : 0x2
[current]<BR>Oct 17 17:26:36 SANfile_m kernel: : ASC=0x4 ASCQ=0x3<BR>Oct 17
17:26:36 SANfile_m kernel: end_request: I/O error, dev sdf, sector 0<BR>Oct 17
17:26:36 SANfile_m kernel: Buffer I/O error on device sdf, logical block
0<BR>Oct 17 17:26:36 SANfile_m kernel: unable to read partition
table<BR>Oct 17 17:26:36 SANfile_m kernel: sd 1:0:1:0: [sdf] Attached SCSI
disk<BR>Oct 17 17:26:36 SANfile_m kernel: sd 1:0:1:0: Attached scsi generic sg2
type 0<BR>Oct 17 17:26:36 SANfile_m kernel: scsi 1:0:1:0:
Direct-Access DGC RAID
5 0219 PQ: 0 ANSI:
4<BR>Oct 17 17:26:36 SANfile_m kernel: kobject_add failed for 1:0:1:0 with
-EEXIST, don't try to register things with the same name in the same
directory.<BR>Oct 17 17:26:36 SANfile_m kernel: [number+85/816]
kobject_shadow_add+0x115/0x1b0<BR>Oct 17 17:26:36 SANfile_m kernel:
[<c02f95f5>] kobject_shadow_add+0x115/0x1b0<BR>Oct 17 17:26:36 SANfile_m
kernel: [lo_ioctl+1125/2528] device_add+0xc5/0x570<BR>Oct 17 17:26:36
SANfile_m kernel: [<c03aefd5>] device_add+0xc5/0x570<BR>Oct 17
17:26:36 SANfile_m kernel: [fc_remote_port_rolechg+127/320]
scsi_adjust_queue_depth+0x9f/0xf0<BR>Oct 17 17:26:36 SANfile_m kernel:
[<c03f9d7f>] scsi_adjust_queue_depth+0x9f/0xf0<BR>Oct 17 17:26:36
SANfile_m kernel: [blk_register_region+18/64]
__blk_queue_init_tags+0x32/0x70<BR>Oct 17 17:26:36 SANfile_m kernel:
[<c02eeb72>] __blk_queue_init_tags+0x32/0x70<BR>Oct 17 17:26:36 SANfile_m
kernel: [sr_get_mcn+2/240] scsi_sysfs_add_sdev+0x32/0x230<BR>Oct 17
17:26:36 SANfile_m kernel: [<c0402882>]
scsi_sysfs_add_sdev+0x32/0x230<BR>Oct 17 17:26:36 SANfile_m kernel:
[<f99445b7>] qla2xxx_slave_configure+0x77/0x110 [qla2xxx]<BR>Oct 17
17:26:36 SANfile_m kernel: [sd_init_command+313/1088]
scsi_probe_and_add_lun+0x8c9/0x940<BR>Oct 17 17:26:36 SANfile_m kernel:
[<c0400859>] scsi_probe_and_add_lun+0x8c9/0x940<BR>Oct 17 17:26:36
SANfile_m kernel: [sr_probe+72/1472] __scsi_scan_target+0x518/0x5c0<BR>Oct
17 17:26:36 SANfile_m kernel: [<c04012c8>]
__scsi_scan_target+0x518/0x5c0<BR>Oct 17 17:26:36 SANfile_m kernel:
[kallsyms_addresses+36259/130252] schedule+0x2df/0x940<BR>Oct 17 17:26:36
SANfile_m kernel: [<c053695f>] schedule+0x2df/0x940<BR>Oct 17
17:26:36 SANfile_m kernel: [sr_init_command+54/944]
scsi_scan_target+0xb6/0xe0<BR>Oct 17 17:26:36 SANfile_m kernel:
[<c04019f6>] scsi_scan_target+0xb6/0xe0<BR>Oct 17 17:26:36 SANfile_m
kernel: [SendIocInit+224/784] fc_scsi_scan_rport+0x0/0x90<BR>Oct 17
17:26:36 SANfile_m kernel: [<c04084b0>]
fc_scsi_scan_rport+0x0/0x90<BR>Oct 17 17:26:36 SANfile_m kernel:
[SendIocInit+344/784] fc_scsi_scan_rport+0x78/0x90<BR>Oct 17 17:26:36 SANfile_m
kernel: [<c0408528>] fc_scsi_scan_rport+0x78/0x90<BR>Oct 17 17:26:36
SANfile_m kernel: [run_workqueue+131/256] run_workqueue+0x73/0x100<BR>Oct
17 17:26:36 SANfile_m kernel: [<c0131dc3>]
run_workqueue+0x73/0x100<BR>Oct 17 17:26:36 SANfile_m kernel:
[autoremove_wake_function+16/80] autoremove_wake_function+0x0/0x50<BR>Oct 17
17:26:36 SANfile_m kernel: [<c01354e0>]
autoremove_wake_function+0x0/0x50<BR>Oct 17 17:26:36 SANfile_m kernel:
[worker_thread+172/256] worker_thread+0x9c/0x100<BR>Oct 17 17:26:36 SANfile_m
kernel: [<c01326dc>] worker_thread+0x9c/0x100<BR>Oct 17 17:26:36
SANfile_m kernel: [autoremove_wake_function+16/80]
autoremove_wake_function+0x0/0x50<BR>Oct 17 17:26:36 SANfile_m kernel:
[<c01354e0>] autoremove_wake_function+0x0/0x50<BR>Oct 17 17:26:36
SANfile_m kernel: [worker_thread+16/256] worker_thread+0x0/0x100<BR>Oct 17
17:26:36 SANfile_m kernel: [<c0132640>]
worker_thread+0x0/0x100<BR>Oct 17 17:26:36 SANfile_m kernel:
[kthread+82/112] kthread+0x42/0x70<BR>Oct 17 17:26:36 SANfile_m kernel:
[<c0135212>] kthread+0x42/0x70<BR>Oct 17 17:26:36 SANfile_m kernel:
[kthread+16/112] kthread+0x0/0x70<BR>Oct 17 17:26:36 SANfile_m kernel:
[<c01351d0>] kthread+0x0/0x70<BR>Oct 17 17:26:36 SANfile_m kernel:
[print_trace_stack+3/16] kernel_thread_helper+0x7/0x14<BR>Oct 17 17:26:36
SANfile_m kernel: [<c0104763>] kernel_thread_helper+0x7/0x14<BR>Oct
17 17:26:36 SANfile_m kernel: =======================<BR>Oct 17 17:26:36
SANfile_m kernel: error 1<BR>Oct 17 17:26:36 SANfile_m kernel: scsi 1:0:1:0:
Unexpected response from lun 0 while scanning, scan aborted<BR>Oct 17 17:26:36
SANfile_m kernel: sd 1:0:1:0: [sdf] Device not ready: <6>: Sense Key : 0x2
[current]<BR>Oct 17 17:26:36 SANfile_m kernel: : ASC=0x4 ASCQ=0x3<BR>Oct 17
17:26:36 SANfile_m kernel: end_request: I/O error, dev sdf, sector
7263453056<BR>Oct 17 17:26:36 SANfile_m kernel: Buffer I/O error on device sdf,
logical block 907931632<BR>Oct 17 17:26:36 SANfile_m kernel: sd 1:0:1:0: [sdf]
Device not ready: <6>: Sense Key : 0x2 [current]<BR>Oct 17 17:26:36
SANfile_m kernel: : ASC=0x4 ASCQ=0x3<BR>Oct 17 17:26:36 SANfile_m kernel:
end_request: I/O error, dev sdf, sector 7263453056<BR>Oct 17 17:26:36 SANfile_m
kernel: Buffer I/O error on device sdf, logical block 907931632<BR>Oct 17
17:26:36 SANfile_m kernel: sd 1:0:1:0: [sdf] Device not ready: <6>: Sense
Key : 0x2 [current]<BR>Oct 17 17:26:36 SANfile_m kernel: : ASC=0x4
ASCQ=0x3<BR></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Is that what you refer as </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> </DIV></FONT>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=tore@linpro.no href="mailto:tore@linpro.no">Tore Anderson</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=dm-devel@redhat.com
href="mailto:dm-devel@redhat.com">device-mapper development</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, October 17, 2007 2:32
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [dm-devel] multibus /
failover and EMC CX600</DIV>
<DIV><BR></DIV>* Hannes Reinecke<BR><BR>> That's the dev_loss_tmo setting.
Just increase it to something to<BR>> your liking.<BR><BR>Oh, sweet.
This knob won't affect how long the layer will hold I/O<BR>before failing it
(like lpfc_nodev_tmo), I assume? (I'm worried about<BR>it taking longer
for dm-multipath to detect failed paths).<BR><BR>I wish it could've been set
to unlimited, though. Seems like there's<BR>always some kind of trouble
with re-adding the devices, either I run<BR>into that -EEXIST bug, or udev
doesn't do it's job properly and the<BR>revived device isn't added back into
the dm-multipath map. In addition<BR>it somtimes breaks queue_if_no_path
with earlier multipath-tools that<BR>doesn't use no_flush on suspend.
Those versions are of course included<BR>in most server distributions...
Sigh.<BR><BR>Regards<BR>-- <BR>Tore Anderson<BR><BR>--<BR>dm-devel mailing
list<BR><A href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</A><BR><A
href="https://www.redhat.com/mailman/listinfo/dm-devel">https://www.redhat.com/mailman/listinfo/dm-devel</A></BLOCKQUOTE></BODY></HTML>