From: Scott M. F. <sf...@ac...> - 2005-04-22 17:34:56
|
On Fri, Apr 22, 2005 at 10:09:32AM -0400, Dominik L. Borkowski wrote: > > Here's a sample scenario which affected us, and explains the problem > in a bit more detail. The steps are in chronological order: > > 1) linux initiator running linux-iscsi drivers attaches to an iscsi target. > Everything goes fine, storage is available, everybody is happy. > > 2) for whatever reason, say a kernel panic, the initiator does not have a > chance to properly log out from the target. > > 3) initiator gets booted up, tries to attach to the target. In our case, the > target decides that there was a previous session with the initiator already, > and refuses any further sessions with this initiator. linux-iscsi relies on the implicit logouts that are part of session reinstatement, as specified in the iSCSI RFC 3720. Targets are required to handle implicit logouts. It sounds like your target has bugs. http://www.faqs.org/rfcs/rfc3720.html 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. -- Scott M. Ferris, sf...@ac... |