[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
iSCSI: Target Resets are Management Functions
Julian, Target Resets are management functions, that is where they belong, not as an iSCSI or SCSI action/command. It is not like this is going to be part of some automatic error recovery function. Target Resets need and deserve this function as part of administration management, it is up the vendors' products to perform, or not, this function, with information they get (or not) from an Admin interaction). I do not think we should support it in the normal iSCSI Protocols. And we should not have to specify the problem avoidance approaches that the implementer SHOULD/MUST take to support this function. You will probably say that it s an implementation decision as to how they avoid the problems, and that is what I am saying, and it belongs to the vendors' Admin function to implement or not. If it is a big enough problem for FC to take it out, with their limited network domain, we certainly should do that also. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: firstname.lastname@example.org Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 03/13/2001 04:27:19 AM Sent by: email@example.com To: firstname.lastname@example.org cc: Subject: Re: iscsi: rev 05 - section 2.5.1 is incomplete John, I respectfully disagree (and I said so in the T10 meeting too). There are better ways to protect against Target Reset than to remove it from your command set. The Target Reset allows you to clean atomically all your LUs. If you are afraid about mistakes by unauthorized initiators we can leave it to the target to reject the command for unauthorized initiators. To obtain the same effect without Target Reset you will have to do a sequence of operations including a reservation for all the units and that might not work out. I bet that they will end-up having to put the same function back through some management interface (SNMP?) and then have to deal with the synchronization. I suggest we leave the commands in and invent a reject-response for initiators we don't want to allow them to do it based on the authentication and/or accessId. Regards, Julo John Hufferd@IBMUS 13/03/2001 12:18 To: Julian Satran/Haifa/IBM@IBMIL cc: email@example.com From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iscsi: rev 05 - section 2.5.1 is incomplete (Document link: Julian Satran - Mail) Julian, based on the response that we got from Robert Elliott @ Compaq, we should probably at least change the draft to remove the Target Reset (Target Warm Reset and Target Cold Reset). This is good news, since these things would have been to much of a problem for iSCSI to permit. I do not really like the Logical Unit Resets either, but at least it should only effect the device you have a right to use, so the impact is a lot less of a problem there, and I think we can live with that. Rober said: Today, T10 approved 01-015r2. For devices compliant with SAM-2 revision 16, Logical Unit Reset is now mandatory and Target Reset is not. Protocols are allowed to mandate Target Reset, make it optional, or not support it at all. In response, the SCSI RDMA protocol working group (defining SCSI over InfiniBand) voted to remove Target Reset support from that protocol. See T10 document 01-108r0 for the (short) proposal. I recommend you do the same and remove both Target Warm Reset and Target Cold Reset task management functions from iSCSI. Other IP protocols don't offer similar resets - a web browser doesn't have a way to reset an http server, a NFS client cannot reset an NFS server, a telnet user cannot interfere with other telnet users. iSCSI shouldn't be any different. John's email mentioned 4 task management functions, which included Logical Unit Reset, and Clear Task Set. The Access Controls feature (by Jim Hafner; going into SPC-3 revision 1) can be used to prevent initiators from logging in and issuing Logical Unit Reset and Clear Task Set. .... --- Robert.Elliott@compaq.com Compaq Server Storage . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: firstname.lastname@example.org Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 03/12/2001 11:31:08 PM Sent by: email@example.com To: firstname.lastname@example.org cc: Subject: Re: iscsi: rev 05 - section 2.5.1 is incomplete Will fix. It should read: For the <Clear Task Set>, the target MUST enter a Unit Attention Condition for all other attached initiators to inform them that all pending tasks are cancelled. After reporting the Unit Attention Condition the target MUST enter the ACA state for any initiator for which it had pending tasks. For the <Target Warm Reset> and <Target Cold Reset> functions, the target cancels all pending operations and are both equivalent to the Target Reset as specified by SAM-2. The target MUST enter a Unit Attention Condition for all attached initiators notifying them that the target is being reset. In addition, for the <Target Warm Reset>, after reporting the Unit Attention Condition, the target enters the ACA state on all sessions and all LUs on which the condition was reported. In addition, for the <Target Cold Reset> the target then MUST terminate all of its TCP connections to all initiators (all sessions are terminated). However, if the target finds that it cannot send the required response or AEN, it MUST continue the reset operation and it SHOULD log the condition for later retrieval. The logging operation MUST be reported through the target MIB. Further actions on reset functions are specified in the relevant SCSI documents for the specific class of devices. Thanks, Julo Ralph Weber <email@example.com> on 13/03/2001 06:09:08 Please respond to ENDL_TX@computer.org To: IPS Reflector <firstname.lastname@example.org> cc: Subject: iscsi: rev 05 - section 2.5.1 is incomplete The following statement is only half true: For the <Clear Task Set>, if the SCSI control mode enables AE reporting, the target MUST send an Asynchronous Event to all other attached initiators to inform them that all pending tasks are cancelled. If the SCSI control mode [page] does not enable AE reporting, then the target MUST establish a unit attention condition for all other attached initiators. In fact, the target must establish a unit attention condition regardless of the contents of the SCSI control mode page. At this is specified in SAM-2. What the control mode pages does is tell the target how to report that unit attention condition; via a Check Condition on the next command received, or via an asynchronous event report. Someone might read the iSCSI version 05 text as releasing them from the SAM-2 requirement, which I doubt will be helpful to the SCSI community at large. The same problem exists in the following 2.5.1 text: For the <Target Warm Reset> and <Target Cold Reset> functions, the target cancels all pending operations and are both equivalent to the Target Reset as specified by SAM-2. Provided that SCSI control mode enables AE reporting, the target MUST send an Asynchronous Event to all attached initiators notifying them that the target is being reset. FYI Ralph...
Last updated: Tue Sep 04 01:05:21 2001
6315 messages in chronological order