|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: connection failure in a multii-connection sessionHere is a swag at it without taking too much time ... This is effectively your item (2) below: All of the tasks on the lost connection will get terminated and internally treated as if a CHECK CONDITION at the target. That means the host will not get a response to each task. The host will timeout on the outstanding commands and will try to abort them but will see the lost connection. The host driver should then return a response to the host saying the command was aborted. Hopefully, the host will re-issue the command and the driver can send it over a good connection. It is true that the terminated commands could have SCSI ordering problems. In that case, the host should be using ACA (Ugh). The good news is that ordered and head of queue commands are usually not used. For item (3) below, are you talking about aborts? Eddy -----Original Message----- From: Alex Aizman [mailto:aaizman@silverbacksystems.com] Sent: Thursday, February 27, 2003 8:48 PM To: ips@ece.cmu.edu Subject: iSCSI: connection failure in a multii-connection session Let's say, Error Recovery Level = 0 and one connection in a multi-connection session has failed. The first question is, could Initiator retain the functioning session with fewer connections (and the ERL being zero)? Assuming the answer is 'yes', here's some of the follow-up questions: Initiator sends Logout(1, CID) on one of the remaining good connections to cleanup the failed connection, ID=CID. Initiator then either: 1) Sends Task Abort for every unacknowledged command. This process will eventually synchronize *this* session sequence numbers. The problem is, once all Aborts are executed, the Target will proceed executing outstanding CmdSNs received on good connection(s), which may cause re-ordering on the SCSI level. 2) Alternatively, the Initiator re-issues all outstanding commands on the good connection(s), without changing their ITTs and CmdSNs. Target receives these commands (some of which may have been already executed), and continues normal processing in the order of CmdSNs. The question is whether Initiator is permitted to retry commands using the same ITT and CmdSN pair on another connection after successful Logout but without explicit re-assignment. Section 6.2.1 in the spec seems to allow that. 3) Finally, is it a hard requirement that Initiator uses the same ITT that was used to send the original command? What's the logic behind this requirement? Alex
Home Last updated: Fri Feb 28 22:19:10 2003 12384 messages in chronological order |