|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: Implicit Termination of Tasksthe cross I_T Nexus is spatial not temporal. If you have a single session - then there is nothing you have to do. Julo
Mallikarjun, > I disagree with your suggestion. > > I believe that cases a, b and c (as written) are necessary and sufficient > cases for generating an internal CHECK CONDITION because > our intent is to deliver on the promise of "ordering in the face of errors > on one I_T nexus", *not* to gurantee the creation of cross-initiator ACA > based on TST and QErr bit settings - simply because there are no iSCSI > ordering guarantees involved across independent I_T nexuses. While I understand the intent, the problem is that CHECK CONDITION is a SCSI mechanism that SAM-2 now defines to have cross-I_T nexus (cross-session) side effects in some cases - iSCSI cannot disregard those side effects because they're inconvenient, and hence if CHECK CONDITION is used with implicit task termination, it ought to be used consistently. > IOW, iSCSI spec today takes the position that the first three cases > are of potential interest to SCSI layer in view of iSCSI's ordering > guarantee while the last case (d) is an iSCSI dynamic that has no > bearing on the ordering guarantee. I think that's a very reasonable > position. The problem with this is that CHECK CONDITION is of interest to the SCSI layer by definition, and the potential cross-I_T nexus side effects make case (d) relevant to SCSI in a way that it was not earlier. I have a problem when the answer to: "When iSCSI loses or tears down connectivity, do implicitly terminated tasks generate CHECK CONDITION and its potential cross-I_T nexus side effects?" is: "It depends on how the connection was torn down or lost." because to my mind that's much worse than "yes" or "no". While it may have no bearing on the ordering guarantee, the different results for the TST=0 case will be a major surprise, especially if ACA is in use. FWIW, the cross-nexus side effects were added to SAM-2 in the relatively recent past - as SAM-2 was when much of the work on iSCSI was done, the current state of iSCSI would be fine as there would have been no way to determine whether the internal CHECK CONDITION was generated in case (d) once the I_T nexus (iSCSI session) vanished. T10 decided to change that situation, and we need to cope with this consequence. > On a related separate topic, the current ASC/ASCQ value specification > for the implicit termination in the iSCSI spec is quite limiting as Eddy > pointed out - I surprisingly overlooked the "array only" qualifier > when I originally > suggested it..... I suggest that we change it to the following - > > 00/06 DTLPWRSOMCAEBK I/O PROCESS TERMINATED I have a note in to Rob Elliott asking the scope of the current ASC/ASCQ value can be expanded. Let's make sure that it can't be before making this sort of annoying minor change at this stage. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ----------------------------------------------------
Home Last updated: Wed Jan 08 14:19:02 2003 12139 messages in chronological order |