On Mar 8, 2006, at 12:49 PM, Vladislav Bolkhovitin wrote:
Steve Byan wrote:
I still don't understand why you are reluctant to return
TASK_SET_FULL or BUSY in this case; it's what the SCSI standard
supplies as the way to say "don't queue too many commands, please".
I don't like out of order execution, which happens practically on
all such "rejected" commands, because subsequent already queued
commands are not "rejected" with it and some of them could be
accepted later.
I see, you care about order. So do tapes. The historical answer has
been to not support tagged command queuing when you care about
ordering. To dodge the performance problem due to lack of queuing,
the targets usually implement a read-ahead and write-behind cache,
and then perform queuing behind the scenes, after telling the
initiator that the command has completed. Of course, this has obvious
data integrity issues for disk-type logical units.
The solution introduced for tapes concurrent with iSCSI (which
motivated the need for command-queuing for tapes, since some
envisioned backing up to a tape drive located on 3000 miles away is
something called "unit-attention interlock", or "UA interlock". Check
out page 287 of the draft revision 23 of the SCSI Primary Commands -
3 (SPC-3) standard from T10.org. The UA_INTLCK_CTRL field can be set
to cause a persistent unit attention condition if a command was
rejected with TASK_SET_FULL or BUSY.
This requires the cooperation of the initiator.
Regards,
-Steve
--
Steve Byan <smb@xxxxxxxxxxx>
Software Architect
Egenera, Inc.
165 Forest Street
Marlboro, MA 01752
(508) 858-3125
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
