James Bottomley wrote:
On Wed, 2006-02-08 at 15:40 +0900, Tejun Heo wrote: ...<snip>... 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.
James is also not disclosing other areas that may fail... - How does multipathing affect this (maybe not dm, but others that exist). - The implicit expectation of the LLDD and the hardware is that commands are placed on the wire in the same order given to queuecommand. However, no where is this mandated. In general, they do keep order. However, I've seen driver implementations that don't dispatch directly to hardware in queuecommand, allowing the intermediate steps to fail and perhaps disrupt ordering. - Some adapters may actually be multipath/raid cards, thus affecting command delivery. - SCSI Transports are not 100% reliable, affecting ordering. For FC, a single Frame corruption could cause a command frame to be dropped thus the next command received and executed out of order. You would not notice an issue until the scsi i/o timeout fires and aborts the i/o. The subsequent i/o may have already completed by that time. Some transports due have command sequence numbering to avoid this, but it's an optional feature. -- james s - : 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
