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

David Ford dford at orca.com
Wed Mar 24 22:37:04 PST 1999


* From the T10 Reflector (t10 at symbios.com), posted by:
* David Ford <dford at orca.com>
*
Bob,

Hello. Just to be sure I understand your algorithm, if a target supports 
256 LUNs and 16 initiators, then the target would have to reserve 256 * 16 
* 2 = 2048 queue slots, correct? That's a big queue!

Orca still feels this is a major unsolved problem in the SCSI protocol, 
particularly as the number of initiators per target and LUNs per target 
keeps growing due to SANs and higher capacity drives.

Can we look at fixing this in FCP-2? ;-)

--Dave

At 08:40 AM 3/22/99 -0800, 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


    -----------------------------------------------------------------
    Dave Ford                                            Orca Systems
    dford at orca.com                                       77 Union St.
    617-926-1399                                 Watertown, MA. 02172

*
* 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