We are reading it. Looking into it... Dan Maslowski Sr. Engineering Manager Embedded Storage Software wk: 303.957.5964 cel: 720.530.8271
http://blogs.sun.com/danmas http://blogs.sun.com/storage Nigel Smith wrote: > 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 _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
