|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] iSCSI: ISID issue summaryFor those who haven't been following the long intricate email discussion between Jim Hafner and myself, let me try to explain the issue. SCSI architecture (SAM2) is based on an intuition that SCSI ports are fixed (e.g., physical) things that have names. So far, the existence of the names has been an intellectual curiosity as they haven't mattered to any visible SCSI functionality. Single port Initiators predominate in both Parallel SCSI and Fibre Channel (e.g., a dual ported Fibre Channel HBA is usually treated as two SCSI Initiators, not a single dual-ported one). Jim tells us that T10 is about to define persistent reserve functionality that depends on the identity of the SCSI Initiator Port - in particular that under some circumstances, persistent reservations will be associated with the Initiator Port independent of the Target Port. Persistent reservations are currently bound to the Initiator Port and Target Port (as well as the LU they affect). For the rest of this message, I'm going to assume that we want to support this functionality. Assuming this and that I got the description in this paragraph right ... ... I need to take a slight detour into pragmatics. Those who configure storage networks rapidly discover the value of consistency and matching configurations. Multi-path I/O configurations tend to want to see access to the same set of LUs consistently across a set of interfaces (i.e., Ports). Between suitable configuration and the aggressive setup of connections to all possible targets, all the required connections come into existence as part of the boot process. Applying this experience to the new persistent reservation functionality, one would expect persistent reservations that are bound only to an Initiator Port to be independent of the Target Port, in that the reservation should span connections to all of the relevant Target Ports and those connections should come into existence as part of the boot process. Turning to iSCSI, the situation gets complicated by the interaction of two factors: - Parallel sessions are permitted down to the interface level (e.g., more than one iSCSI session may exist that uses IP addresses A and B to connect iSCSI Initiator I to iSCSI Target T). - SCSI disallows parallel nexii (i.e., more than one session between the same two SCSI Ports). If SCSI Ports are mapped to hardware entities such as network interfaces in iSCSI, the opportunity for parallel sessions between the same pair of network interfaces vanishes. In order to avoid that outcome, iSCSI Initiator Ports have to be mapped to software entities. To date, the ISID has been used to identify those software entities, and the only rule on their allocation is: ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal Group (SCSI target port), then can be only one session with a given ISID (identifying a SCSI initiator port). See 3.12.8. In order to get the expected outcome of the new functionality being defined by T10, the same ISID has to be used to establish all the connections that the persistent reservation is supposed to span. Unfortunately, that's above and beyond what iSCSI requires - the relevant text about doing this in -08 is: The "ISID rule" does not preclude the use of the same ISID from the same iSCSI Initiator with different Target Portal Groups on the same iSCSI target or on other iSCSI targets "does not preclude" is rather weak language for something that's essential to making a piece of SCSI functionality work. If an iSCSI implementation uses a different ISID for every session (which is also not precluded by the current text), then persistent reservations will never span Targets or Target Ports for that implementation despite T10's best efforts and intentions. IMHO, allowing that outcome is *wrong* (and this is the source of the difference of opinion between Jim and myself). The correction to this involves what Jim has called "conservative reuse" of ISIDs. This is something like for each ISID that an implementation uses, a connection with that ISID is made to every possible Target Portal Group of every possible Target. I suspect a longer explanation than this will be needed, including a discussion of the desirability of avoiding a situation in which the same ISID is used by two iSCSI implementations that are part of the same Initiator and set up sessions concurrently. IMHO, if we want to support persistent reservations at this stage that span target ports, we need to replace the "does not preclude" language with a REQUIREMENT for conservative reuse to avoid a situation in which SCSI functionality that works consistently with other transports works inconsistently with iSCSI (i.e., doesn't work with iSCSI implementations that don't do conservative reuse). Stepping back from the assumption that support for port-spanning persistent reservations is required, I observe that the conservative reuse rule impacts all implementations, even those that will never use such persistent reservations because ISID is a mandatory part of the iSCSI protocol. If a text key were used instead, only those Initiators that want to support this functionality on which T10 is "crossing a few t's and dotting a few i's" are affected (the text key is optional). The text key would be subject to a conservative reuse rule similar to the one that would be needed for ISIDs, and once T10 finishes the i's and t's, we can precisely reference the SCSI features (persistent reservation expansion) that require use of this text key. In addition, text keys have much better alternatives for dealing with conflicts than ISIDs - if a text key conflicts, it is possible to continue the negotiation with a different text key, whereas ISID conflict is fatal to one of the two sessions involved. As Jim has previously observed, changing the text key (e.g., generate a large random number in response to a conflict), results in a situation that can be dealt with by software that uses persistent reservations, although this departure from conservative reuse should only occur as a consequence of some sort of configuration mistake or bug. At the tail end of this reasoning chain is the observation that use of this text key leaves the ISID without value/purpose, and hence would call for its removal (or perhaps designation as a reserved field). Putting on my WG chair hat for a moment, I can accept either alternative outlined above: - Add conservative reuse to the ISID rule. - Use a text key for iSCSI port identification. But I'm not comfortable with the current situation in which iSCSI implementations are permitted to break T10-defined SCSI features that will work as expected in other SCSI transports. I hope this now makes sense to more people than just Jim and I, and I apologize for the length of this message, as this is a somewhat subtle issue. Comments? --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------
Home Last updated: Wed Oct 10 11:17:30 2001 7177 messages in chronological order |