|
|
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
On Feb 1, 2006, at 2:22 PM, Black_David@emc.com wrote:
Consolidating responses to Eddy and Bill. The most important piece of this message is the last paragraph (repeated here): ACA and multi-connection iSCSI sessions are a lousy fit. Would it be worth saying that ACA SHOULD NOT be used on multi-connection iSCSI sessions and initiators are responsible for dealing with the response ordering issues that arise when ACA is used on a multi-connection session? That would be mostly consistent with RFC 3720 and impose no ACA implementation burden on targets. Please comment.
I like it. It means I don't have to do anything extreme. :-)
--- William Studenmund wrote:-- (1) The SCSI response indicating that CHECK CONDITION has caused establishment of ACA could get ahead of a response to a command completed prior to establishment of ACA.Well, the first question that comes to my mind in these cases is what does Fibre Channel do in these cases on a large SAN? Or what is FC doing on SANs that are bridged over IP? :-) We shouldn't beat ourselves up to do stuff the FC doesn't. :-)Fibre Channel doesn't have multi-connection sessions, and hence these ACA-related reordering-across-connections problems don't arise.
Ok.
I was going to suggest a bit of a tangent here by suggesting we pull in a post-SAM-2 feature and add support for the Query Task Task ManagementFunction. However I think that that function only indicates if a task is in the task set or not. Hmmm... Maybe that is enough.That's a separable item. At some point, someone will write the draft to update iSCSI to SAM-3 (backwards compatible - any incompatible behavior differences have to be negotiated), and QUERY TASK would be part of that.
Sounds good.
I really have all of these delays we are building into the target. If we are in a MC/S situation, shouldn't we expect the initiator to carry some of the load? Put another way, if the initiator can't handle ACA cleanup, maybe it shouldn't issue commands with NACA set. :-)The issue here is that multi-connection iSCSI sessions without target synchronization of responses add out-of-order response cases for ACA that a SCSI initiator isn't expecting. RFC 3720 says ACA is entirely a SCSI-layer issue.
Ahh... I was a bit sloppy. A better way to say this may be that an iSCSI initiator shouldn't accept CDBs with NACA set if it can't handle cleanup. :-)
So should the (iSCSI) initiator complain if commands are issued with NACA set and we're in MC/S?
The problem is that there is no way to indicate target status across the whole session; status is a per-connection thing (which is usually great!). The only other thing I can think of is to add a new async eventindicating we entered ACA and that all status messages with StatSN lessthan this one were completed before the event.And issue that on every connection in the session for ACA? IMHO, it's probably better to wait for the status acks, issuing NOPs as needed to get them (as Eddy notes above).
Yes, on every connection. My thought was that the special event would have the advantage that it immediately flags that something is going on. Also, once we get this event on all connections, we know we're done (modulo Status SNACKing).
But just not using ACA in MC/S is easier. :-)
-- (2) An ACA ACTIVE status response could get ahead of the SCSI response that indicates establishment of ACA.Is this issue really a special worry?As I understand SAM-2, this can always happen. In table 25, if QErr is00b and TST is 000b, some OTHER initiator triggering ACA can put our port into ACA ("all enabled tasks from all SCSI initiator ports"). Sothere may not even be a status event with the CHECK CONDITION on any ofour connections. Thus we can suddenly find ourselves in ACA. :-|Right, but what if they're not? Also, an initiator who reacts to thissituation by retrying the task (on the assumption that the other initiator will get out of ACA eventually) is in for a surprise when the ACA turns out to be its own fault. I would hope the common case for ACA is single initiator devices or TST = 001b (task set per initiator), but I don't know.
I agree it really only makes sense in a single-initiator device (well, usage). At least as I understand why you want ACA, which was to be able to make tape command streams work right in face of EOT events.
Between (1) and (2) it's probably a good idea to advise initiator implementers that the synchronous nature of ACA makes it a poor fit with the concurrency of multi-connection iSCSI sessions.Indeed. Consider the further wrinkle of a slow initiator (or slow connections) in a QErr 00b/TST 000b scenario. Another initiator could have cleared ACA and RETRIGGERED ACA before the one initiator could have cleared it. :-)Again, I think ACA and TST = 000b (single task set for all initiators) are a lousy match for multi-initiator devices. That would also be worth saying in the implementers guide.
Ok. Agreed.
Comments? (and sorry for the length)I think this is a mess. For ACA to work well, it really needs the SCSIworld to be different than it is normally for iSCSI. :-(I think it's slightly more specific as noted above - ACA and multi-connection iSCSI sessions are a lousy fit. Would it be worth saying that ACA SHOULD NOT be used on multi-connection iSCSI sessions and initiators are responsible for dealing with the response ordering issues that arise when ACA is used on a multi-connection session? That would be mostly consistent with RFC 3720 and impose no ACA implementation burden on targets.
As I make targets, I really like this idea. :-) Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips
[IETF] [Linux iSCSI] [Linux SCSI] [Linux Resources] [Yosemite News] [IETF Announcements] [IETF Discussion] [SCSI]
|
|