Hi all, I'm facing a somewhat strange situation. As a part of testing a multipath solution, I've written a script that simulates the failure and recovery of one path which happens to be an iSCSI connection. It's running on the target side, periodically stopping and starting it. After some successful failovers and failbacks the SCSI device on the initiator side seems to block all operations on the low level (eg. non-multipathed) device. However the iSCSI session seems to reestablish properly. I'm seeking your advice about how to get this device to work again. I don't even know what can cause such a problem. Is it the SCSI layer, the initiator or the target? I'm quite sure that a relogin could solve this, but I'd like to avoid that if possible.
I'm running Open-iSCSI 2.0.871.3, kernel 2.6.32 as distributed in Debian Squeeze on x86-64 hardware on both sides, with IET 1.4.20.2 as the target. Regarding the SCSI device in question, I see log entries like this: kernel: [538607.929428] connection3:0: detected conn error (1020) iscsid: Kernel reported iSCSI connection 3:0 error (1020) state (3) kernel: [538728.180083] session3: session recovery timed out after 120 secs iscsid: connect to [ipaddress]:3260 failed (Connection refused) multipathd: sdc: directio checker reports path is down iscsid: connect to 193.225.36.16:3260 failed (Connection refused) iscsid: connection3:0 is operational after recovery (34 attempts) multipathd: sdc: directio checker reports path is down I'm quite suspicious about the last two lines: if the connection is operational, why is the path still down? Any idea about handling this situation? Thanks, -- cc -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
