> > I never once saw anything other than simple tagged requests
You can download 3rd party utilities that exercise every single queue
method. Just pray your customers never install any of them or Windows
never gets around to performance optimization using advanced queuing.
A SCSI pass through app/driver can pass whatever it wants, and drivers/apps
that use pass through are responsible for assuring correct operation.
The original question was about performance optimization being done by the
standard OS components, specifically the question was “I thought TCQ solved
all these problems years ago”, and a very clear answer on Windows is no, TCQ
does not solve all the request ordering issues, you need to wait for request
completion.
> There are no specifications other than the disk class driver sources
that might describe this areaYes there is: T10.
That describes how the disk reacts, it says nothing about what requests the
standard Windows OS will pass down. My guess is the Windows cluster software
would not include tests for reservation behavior if all storage devices
perfectly followed the specs.
I am still unconvinced that browsing sources and looking at things in a
debugger is a valid way to pick and choose what should go into driver
design.
You’re free to suggest a better way when there is no other information
available, really, what do you propose? If you can get Microsoft to send me
a copy of the source code, I’m sure I could make good use of it at times. My
guess is no device implements EVERYTHING in T10, they pick and choose the
stuff that has value or is required for certification testing. There become
defacto subsets of standards, which are often not documented anyplace. Even
something as well documented as the TCP/IP protocol has a lot of variations
in implementations.
Meet the specifications, don’t cut corners. It is not difficult
and probably will save time and increase customer satisfaction in the
long run.
Most specs have fuzzy areas. The real world has bugs and variations on
interpretations of specs. It doesn’t really help when a whole system doesn’t
work correctly to say “my part follows the spec, everybody else can just fix
their area”. Part of not cutting corners is understanding how reality
doesn’t match the specs, in addition to knowing what’s in the specs.
Just a few weeks ago, I was writing a driver for a hardware device, with the
chip specs in front of me. The device would not do anything, and after some
digging found some information (not in the docs) that to make that chip work
you had to write an undocumented value to an undocumented register during
initialization. I had the chip vendor documentation with the recommended
initialization sequence in front of me, and it didn’t work.
A LOT of devices don’t exactly follow their specification documents, and
take some magic to actually make work. I’ve spent a lot of my life looking
at a lot of spec documents, and have had some pretty large battles to get
component owner to fix what I believe was their non-conformance. Some of
those battles were successful some not. In the end, it’s often the driver
writers job to work around hardware bugs. Reality is, spinning a new ASIC
revision often costs millions of dollars, and a lot of driver workarounds
can be written for millions of dollars. You should look at the Intel
processor errata sometime. Even processors don’t work quite the way their
specs say. I’d bet there are a bunch of people reading this list nodding at
what I’m saying.
Jan