The debug trace from the iscsi target looks interesting. We really need the developers to look at this, but for what it's worth, here's my reading of it.
Between "Wed Oct 22 19:12:07 2008" and "Wed Oct 22 19:12:08 2008" it looks like a normal iscsi connection and session initiation. This is connection CON0 and session SES1. Then there is a delay of 2 minutes 50 seconds, with nothing logged. Then at "Wed Oct 22 19:14:58 2008" a second connections starts - CON1. This progresses until it completes the set-up of the seconds session - SES2 Then immediately the first session SES1 says "implicit shutdown", and then we see the original session torn down. Event T8, transitions us from state 'S5_LOGGED_IN' to state 'S1_FREE' (Note these states & transitions do not necessarily correspond to those defined in rfc3720) Ok, lets look at the code. You can find "implicit shutdown" here: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/iscsi/iscsitgtd/iscsi_sess.c ..look in function "session_validate()" The comment for this function is: 597 /* 598 * []---- 599 * | session_validate -- do what the name says 600 * | 601 * | At this point the connection has processed the login command so that 602 * | we have InitiatorName and ISID at a minimum. Check to see if there 603 * | are other sessions which match. If so, log that one out and proceed with 604 * | this session. If nothing matches, then link this into a global list. 605 * | 606 * | Once we support multiple connections per session need to scan list 607 * | to see if other connection have the same CID. If so, log out that 608 * | connection. 609 * []---- 610 */ And just before the "implicit shutdown" section of code, we have this comment: 644 /* 645 * Section 5.3.5 646 * Session reinstatement is the process of the initiator 647 * logging in with an ISID that is possible active from 648 * the target's perspective. Thus implicitly logging out 649 * the session that corresponds to the ISID and 650 * reinstating a new iSCSI session in its place (with the 651 * same ISID). 652 */ 'Section 5.3.5' is refering to RFC3720, the rfc defining iscsi. http://tools.ietf.org/html/rfc3720 5.3.5. Session Reinstatement, Closure, and Timeout Session reinstatement is the process of the initiator logging in with an ISID that is possibly active from the target's perspective. Thus implicitly logging out the session that corresponds to the ISID and reinstating a new iSCSI session in its place (with the same ISID). Therefore, the TSIH in the Login PDU MUST be zero to signal session reinstatement. Session reinstatement causes all the tasks that were active on the old session to be immediately terminated by the target without further notice to the initiator. The initiator session state MUST be FAILED (Section 7.3 Session State Diagrams) when the initiator attempts a session reinstatement. Session closure is an event defined to be one of the following: - A successful "session close" logout. - A successful "connection close" logout for the last Full Feature Phase connection when no other connection in the session is waiting for cleanup (Section 7.2 Connection Cleanup State Diagram for Initiators and Targets) and no tasks in the session are waiting for reassignment. Session timeout is an event defined to occur when the last connection state timeout expires and no tasks are waiting for reassignment. This takes the session to the FREE state (N6 transition in the session state diagram). :-----------------------------------------------------------------------------: Ok, those are the facts, as I see them. I will have to go away and read my iscsi book http://books.google.co.uk/books?id=hvtSAAAAMAAJ ... to try & understand the relevance of the above to this situation. Hopefully some of the developers of Solaris iscsi target are reading this and can jump in and give an opinion. Regards Nigel Smith -- This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
