I am running heavy load test to an array connected to SLES10 SP2
system (2.6.16.60-0.21) using open-iscsi and device-mapper multipath
that comes with the distro.
The test from time to time will also inititate lun reset. For
whatever reason, after couple hours I/O would just hang on a path.
And iscsiadm -m session -P3 would show that a path is in "recovery"
state (see below) and while other other paths are "running" state
Current Portal: 192.0.1.144:3260,1
Persistent Portal: 192.0.1.144:3260,1
**********
Interface:
**********
Iface Name: default
Iface Transport: tcp
Iface Initiatorname: iqn.1996-04.de.suse:
01:7284eb499690
Iface IPaddress: 192.0.1.97
Iface HWaddress: default
Iface Netdev: default
SID: 1
iSCSI Connection State: LOGGED IN
iSCSI Session State: Unknown
Internal iscsid Session State: NO CHANGE
************************
Negotiated iSCSI params:
************************
HeaderDigest: None
DataDigest: None
MaxRecvDataSegmentLength: 131072
MaxXmitDataSegmentLength: 524288
FirstBurstLength: 262144
MaxBurstLength: 2097152
ImmediateData: No
InitialR2T: Yes
MaxOutstandingR2T: 1
************************
Attached SCSI devices:
************************
Host Number: 4 State: recovery
So while other paths are deem good by iscsi and multipathd agrees
according to output in /var/log/messages, no test I/O nor multipathd
check I/O is going out to the wire on the so-called "bad" path. It
seems they're being held back and never completed.
On the trace, on the "bad" path the only I/O is iSCSI nop . So who is
holding back all the I/O? scsi mid-layer or iscsi or both?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---
