> > The biggest win with tagged commands is that you can
> > issue multiple commands to a target and have the target
> > do the ordering. The target will do the ordering to
> > optimize the operations as it's doing head seeks and
> > crossing platters thus yielding a higher throughput
> > and minimizing the time due to seeking..
> 
> Except the buffer cache and the disksort routine are supposed to do
> that already.
> 
> It could well be that the target gets it wrong and the performance
> gets worse.  There is a CSRG paper about such an experience with a
> non-SCSI controller that did it's own ordering.


People who say "use disksort" are missing something: concurrency.

There's a lot of literature out there, that's been put out recently,
about the fact that exposing I/O concurrency to the OS, and to the
hardware wins significantly.

In the recent SOSP paper that my group did, we saw some occasionally
quirky -- but always better -- performance by exposing more concurrency
to the drive(s).  (The one particular case i can think of, that i
think was mentioned in that paper was a case where we were doing grep
string * for the files in one manual section, and disclosing our future
file accesses to the OS via hints, so that it would prefetch the data.
w/ one request outstanding at the drive, we got horrible performance,
with many, we got great performance...  turns out that the layout
of the files on-disk -- done by the FFS -- was EXACTLY OPPOSITE
optimal, because of the fact that the files were added to the
directory in almost reverse order.)

Consider also the case where you're talking about a RAID4 controller that
appears as a LUN on a SCSI bus.  How can you _hope_ to get the maximum
bandwidth that it provides if you've only got one outstanding request
at a time, because it's going to have several spindles completely idle!


While i believe that disksort etc., do the right thing, you cannot get
maximum bandwidth out of modern disks and disk subsystems if you don't
expose concurrency of access to the disks.



chris