James Bottomley wrote: > 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. Oh... I see. How many drivers do that? I can't think of good reasons to report BUSY via IRQ for simpler transports (SATA/SPI). Maybe enable ordered-tag selectively? > > 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. Actually blk layer will do the sorting part (this is what req->ordcolor is for). Block drivers are only required to not successfully complete later requests while retrying earlier ones, so setting QErr and retrying all on-the-fly requests should do it (no EH code change). > 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. -- tejun - : 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
