bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=15565 Summary: SCSI Generic queueing completes commands in reverse order Product: IO/Storage Version: 2.5 Kernel Version: 2.6.18-2.6.32 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: SCSI AssignedTo: linux-scsi@xxxxxxxxxxxxxxx ReportedBy: mh-linux-kernel@xxxxxxxx Regression: No I've noticed after queueing the first command, subsequent commands appear to be executed and complete in reverse order. The SCSI Generic HOWTO says "By default, read() will return the oldest completed request that is queued up." This could also be a performance defect if it's what's really happening since it isn't desirable behavior if, for example, ios are typically ordered by lba and issued one at a time by kernel to a non queueing block device. This reverse order behavior is trivial to reproduce; just queue 16 concurrent INQUIRY commands. The following are typical results I get from initially queueing 16 READ_10 commands. Completion Command # hdr.driver_duration (us) Order 1 22 14979 2 20 14981 3 19 14982 4 17 14984 5 16 14985 6 15 14986 7 14 14988 8 12 14990 9 11 14991 10 10 14992
I have been told that is a feature :-) The SCSI mid level processes commands from pass-throughs (e.g. sg and bsg) in LIFO order. For certain types of error processing it makes sense. For READs and WRITEs it makes no sense. Doug Gilbert -- To unsubscribe from this list: 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
