On Wed, 2006-02-08 at 11:22 -0500, James Smart wrote: > James is also not disclosing other areas that may fail... > > - How does multipathing affect this (maybe not dm, but others that exist). Hey, with block level multi-path that's now officially Someone Else's Problem. (And it's also a problem for software RAID as well). > - 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. OK ... this acceptance problem is pretty much identical to the BUSY/QUEUE_FULL one. > - Some adapters may actually be multipath/raid cards, thus affecting command > delivery. This shouldn't be more of a problem than SCSI devices. The issue here is caching. A raid controller with a non-battery backed cache may decide to ack commands before they hit the medium. However, as long as they expose this in the caching mode page and support the FUA bit of 10 byte commands, we should be able to cope (and yes, I know there are drivers that currently don't get this right). > - 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. Yes, but again, this is identical to BUSY/QUEUE_FULL. As long as you can get status return from the command in-line you can still preserve ordering. 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
