TASK SET FULL Definition(s) in FC-TAPE and SAM-2

Larry Chen larryc at maxstrat.com
Mon Mar 22 11:35:29 PST 1999


* From the T10 Reflector (t10 at symbios.com), posted by:
* Larry Chen <larryc at maxstrat.com>
*
This is a multi-part message in MIME format.
--------------6D3B1095B68142004CEAA782
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit

I took the liberty to forward this email to
the interop reflector.

-Larry
Bob Snively wrote:

> * From the T10 Reflector (t10 at symbios.com), posted by:
> * Bob Snively <Bob.Snively at Ebay.Sun.COM>
> *
>
> George Ericson's note called to mind a recommendation we have made to
> vendors of targets designed to support multiple initiators.  We strongly
> recommend that a small number (2 or more) of "queue slots" be reserved
> for each logical unit and for each initiator that the target has
> identified.  In the case of FCP, this is simple, since each initiator
> must log in with each target.  In the case of parallel SCSI, the
> problem is a bit more challenging, but the number can either be
> pre-specified, determined empirically by the target, or assumed to be
> the entire device id address space.
>
> The remaining queue resources, if any, should be put in a pool
> available regardless of initiator.
>
> By guaranteeing this, no initiator is locked out, since as commands
> complete for that initiator, the queue slots dedicated to that
> initiator remain available to it.  No initiator will get a queue full
> indication with no outstanding commands.  At the same time, any
> initiator with lots of work to do will obtain a relatively large number
> of queue slots by competition for the pooled resources.
>
> Using this approach, a relatively simple algorithm can be used by
> device drivers to ratchet the assumed queue size up, while guaranteeing
> that the initiator will never stall against the logical unit.
> Completion of queued commands can be used as an indication that a
> previously identified QUEUE FULL condition may no longer be present and
> that the previously rejected command may be retried, since this will
> eventually be guaranteed as the number of queued commands outstanding
> dips below the guaranteed number of slots for that logical unit.
>
> I assume that there are lots of variations that could be done on this
> approach, including heuristic incrementing of guaranteed slots for
> active initiators.
>
> I see the BUSY state as something that a well-behaved target will rarely
> offer, and then only for an unavoidable condition and a short time.
> Longer term "busy" states should be indicated by the appropriate not-ready
> check condition.
>
> Bob
>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at symbios.com

--------------6D3B1095B68142004CEAA782
Content-Type: text/x-vcard; charset=iso-2022-jp;
 name="larryc.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Larry Chen
Content-Disposition: attachment;
 filename="larryc.vcf"

begin:vcard 
n:Chen;Larry
tel;fax:(408) 383-1616
tel;work:(408) 383-1600 (x116)
x-mozilla-html:FALSE
url:http://www.maxstrat.com/
org:Sun Microsystems, Inc. (formerly MAXSTRAT Corporation);Engineering Dept.
adr:;;801 Buckeye Court;Milpitas;CA;95035-7408;USA
version:2.1
email;internet:larryc at maxstrat.com
title:Software Engineer
x-mozilla-cpt:;-4336
fn:Larry Chen
end:vcard

--------------6D3B1095B68142004CEAA782--

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





More information about the T10 mailing list