On Wed, 2006-02-08 at 15:40 +0900, Tejun Heo wrote: > Now that new ordered implementation is in the mainline, we can properly > use ordered-tag during barrier sequence. As noted in the barrier doc, > the problem with the current SCSI midlayer is that scsi_request_fn() is > not atomic w.r.t. q->queuelock, so even if ordered-tag requests leave > request queue in the correct order, they can be reordered while they are > being issued by SCSI midlayer. Unfortunately, though, this is only half the problem. The other half is busy/queue_full processing and error recovery For the first: busy/queue_full processing, the issue is that when we send out a command, we could get a BUSY or QUEUE_FULL return which comes back to us via IRQ context. Unfortunately, we could have multiple commands that do this and a command will be accepted as soon as the busy condition alleviates, so we could see say two commands go down in order, the first one will get BUSY, the second is accepted and only then do we get the IRQ that says BUSY to the first ... now we have out of order execution. For the second: Depending on the mode page (the QErr bit of the queueing page), most devices fail only a single command. We can set the QErr bit to return every command after the failing one (thus ensuring execution order), but the error handler would have to take them all back and resort them for submission. I think the first problem has to be solved before we can turn on ordered tag based barriers. I'm ambivalent on the second; we could probably mark ordered tag based barriers as "caveat emptor" while we work on the EH problem in parallel. James - : 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
