RE: iscsi: rev 05 2.5.1 requires ACA support

[Charles Monia <cmonia@NishanSystems.com>]

Hi:

I though the action items in the following extracts from the T10 CAP minutes
were intended to address this issue.  What happened?

From T10 SCSI Commands, Architecture, & Protocol Working Group Meeting
Minutes --
January 17, 2001 T10/01-007r1

"4.4 Queue Locking for Busy, Task-Queue-Full, & Reservation Active [Satran]

"Julian Satran presented a discussion regarding the lack of ACA-like
interlocks on the BUSY, TASK SET FULL, and RESERVATION CONFLICT status codes
(01-048r0). The group tentative agreed to resolve the issue by providing an
initiator selectable way to make BUSY, TASK SET FULL, and RESERVATION
CONFLICT status codes translate to CHECK CONDITION status with informative
sense data. Ed Gardner agreed incorporate the tentative resolution in the
next revision of his proposal (see agenda item 5.5)."

"5.5 Unit attention issue (00-359) [Gardner]

"Ed Gardner described a problem where in autosense clears a unit attention
condition (00-359r1). Basically, the combination of commands in flight and
autosense results in a condition where the initiator may not be able to stop
commands that should be stopped based on unit attention conditions. Ed asked
for recommendations on how the
initiator should indicate that the new feature was being requested
(recognizing that there must be a way to maintain the current behavior).
Options discussed were Control byte (plus INQUIRY bit), Control mode page,
and protocol specific. The group recommended using the Control mode page and
Ed agreed to bring a specific proposal based\ on that recommendation to the
next meeting."


Charles


> -----Original Message-----
> From: Charles Binford [mailto:Charles.Binford@BlueSpruceNet.com]
> Sent: Friday, March 16, 2001 11:57 AM
> To: ips@ece.cmu.edu
> Subject: RE: iscsi: rev 05 2.5.1 requires ACA support
> 
> 
> (sorry this got kind of lengthy - but I do have proposed 
> solution to what I
> believe are the problems below)
> 
> Julian,
> I don't think iSCSI needs to look at the NACA bit in the CDB 
> - I don't think
> iSCSI should care about ACA at all.
> 
> In my 10+ years of working with SCSI disk products I've yet 
> to see a host
> driver that cared about ordering.  As David said below, if there is an
> ordering dependency then the application waits for completion 
> of the first
> I/O before releasing the second.  One gets the best 
> performance from a SCSI
> block I/O target (from a single disk to a large RAID 
> controller) by issuing
> queued commands with simple tags and allowing the target to 
> freely re-order
> the commands internally.  When an error happens it doesn't matter what
> commands are in-flight because they are all independent I/Os. 
>  This is the
> way high performance SCSI disks and disk subsystems work.  It 
> would be a
> mistake (in my opinion) for iSCSI to come in and mandate the extra
> complexity of ACA to handle a corner case most of the SCSI world it is
> trying to penetrate doesn't care about.
> 
> Granted, tape and other sequential devices are a different 
> story.  However,
> I participated heavily in T11 for 2 to 3 years helping develop a error
> recovery scheme that would allow SCSI tape devices to work 
> with FC.  The
> bottom line, however, was that while we talked about it over 
> and over, no FC
> tape vendor had a device that supported queuing.  If you 
> don't queue, then
> nothing is in-flight when an error occurs.  (streaming is 
> accomplished by
> caching in the target).  After this drug on for a couple of 
> years and the
> complexities of queuing to sequential devices became evident, 
> a new project
> was started in T10 to develop a new tape command set that 
> included relative
> block addresses in the CDB - making the new tape model very similar to
> disk - each command can be interpreted independently and 
> precise delivery
> order is not a fundamental requirement.
> 
> ===================