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

Bob Snively Bob.Snively at Ebay.Sun.COM
Wed Mar 17 13:57:17 PST 1999

* From the T10 Reflector (t10 at symbios.com), posted by:
* Bob Snively <Bob.Snively at Ebay.Sun.COM>

The document is available on the T11 website, www.t11.org at the URL


Some of the text has been moved from FC-TAPE to FCP-2 during the 
development of the standards.

The command ordering question you have asked is addressed in FC-TAPE
by using the CRN (Command Reference Number) defined in FCP-2 and
by using ordered queueing.

Hope that is some help to you.


> X-Sender: jnemeth at pop3.concentric.net
> Date: Wed, 17 Mar 1999 12:22:08 -0700
> To: t10 at Symbios.COM, fc at nsg0.network.com
> From: "Joseph C. Nemeth" <jnemeth at concentric.net>
> Subject: Re: TASK SET FULL Definition(s) in FC-TAPE and SAM-2
> Mime-Version: 1.0
> * From the T10 Reflector (t10 at symbios.com), posted by:
> * "Joseph C. Nemeth" <jnemeth at concentric.net>
> *
> A couple of comments/questions.
> First, I've been looking around trying to find the FC-TAPE draft
> specification, and I can't find it. Where did this end up?
> Second, there's something I don't understand about the QUEUE FULL handling,
> and command retries in general. With parallel SCSI, the initiator and
> target are locked into a rigid phase sequence handshake, such that the
> initiator is guaranteed to receive the QUEUE FULL status before it is free
> to issue the next command. Therefore, on receiving QUEUE FULL status, the
> initiator can simply hold up its own queue, and retry the command when it
> receives status from some previously queued command.
> Unless something has changed, FC Class 3 has no reliable handshake
> mechanism for informing the initiator that the command has been received,
> so "queuing commands" on the part of the initiator consists of simply
> spewing out command IUs. An initiator that is issuing queued command IUs
> may not receive QUEUE FULL status from the target until after it has
> already issued subsequent command IUs, *some of which may be accepted by
> the target* as the target's queues clear. Therefore, retrying the command
> that received QUEUE FULL status results in out-of-order delivery of
> commands to the target. Note that out-of-order delivery will occur even if
> all of the commands are sent with the Ordered Queue flag. Therefore, the
> proper recovery mechanism for a Class 3 initiator is to not only queue up
> the affected command for retry, but also all subsequent commands that it
> has already issued (whether accepted by the target or not), AND to issue an
> ABORT to the target for all the commands that were sent after the command
> that resulted in the QUEUE FULL status, hoping that the target hasn't
> already started altering the state of the media in response to those
> accepted-out-of-order requests. For rewritable disk devices, whether the
> media is altered is perhaps irrelevant. For sequential or non-rewritable
> devices, the media has probably just been ruined.
> So is this discussion of QUEUE FULL/BUSY/retry taking place in the context
> of FC Class 2 and/or command acknowledgement ONLY?
> Joseph C. Nemeth          Precision Algorithms          (970) 226-5427

* 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