dledford@redhat.com said:
> This I'm not following. If you get a QUEUE_FULL from the adaptec
> driver, then the commands you are pushing back should still be tagged
> and no stall should be required beyond just waiting for any
> outstanding command on the drive to complete or for a timeout to
> pass. It should not require any untagged type stall where you have
> to drain the entire pipeline...
Ah, but that was the problem in the blk generic tagging. only requests of
type REQ_CMD get tagged, so say the SD driver gets a block read request as a
REQ_CMD, translates it into a SCSI READ, sends it through the mid-layer to the
low layer driver which requests a block layer tag but eventually responds
QUEUE_FULL. Now the command gets pushed back to the blk queue head as a
REQ_SPECIAL (and as part of the push back, we have to finish the tag since
command moves from the tag queue to the blk queue), which to the scsi mid
layer means request with already formulated SCSI command so don't go back
through the upper layer driver again. The problem is that when this command
comes back again into the scsi mid layer for execution it would now do so as
an untagged command because the blk_queue_start_tag() code will only tag
REQ_CMD requests, and hence we get a queue stall every time the low level
driver responds QUEUE_FULL.
This was the behaviour (in the blk layer) I was objecting to---on the second
go around, we request a tag using blk_queue_start_tag() but get denied because
the request isn't of the correct type---and why I think the
blk_generic_start_tag() needs to allow REQ_SPECIAL requests to be tagged.
> I would think that, eventually, the bio layer will support I/O fencing
> via tagged commands (aka, ext3 needs an I/O fence and the bio layer
> does as needed to enforce that, which on scsi may mean an ordered
> queue tag is generated instead of a regular tag and on IDE it may
> mean something else). It will have to be able to tell that some of
> these conditions have been satisfied in those cases, so I see no
> reason why it shouldn't be made aware of them now. Just my $.02
I've actually already put this code into the mid layer patch (the
scsi_populate_tag_msg() function in scsi.h) to generate an ordered tag for the
case where the request is marked REQ_BARRIER.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:29 EST