Craig Ringer wrote: > M. Edward (Ed) Borasky wrote: > >> At the CMG meeting I asked the disk drive engineers, "well, if the >> drives are doing the scheduling, why does Linux go to all the trouble?" > > One big reason is that Linux knows more about the relative importance of > I/O operations than the individual drives do. Linux's scheduler supports > priorities in its queuing, and is able to do things like try to perform > small blocking reads before long non-blocking writes in order to improve > overall system throughput. > > The individual drives just don't have the knowledge to make these > decisions. All they can really do is try to fetch the set of blocks > currently requested in the smallest possible time. This can even be > harmful if, in order to improve overall throughput, the drive reorders > what to the OS is a very high priority operation and performs it later > than it would've if following the request queue directly. > > I've had to modify the 3ware driver to set very shallow request queues > for similar reasons. It was using very deep queuing and the controller > seems to do very stupid request queuing where it maintains a single deep > per-controller queue rather than per-array queues, so I was getting > AWFUL request latencies on high priority small reads when bulk I/O was > in progress elsewhere - even on another array on the same controller. > > I've also had to turn NCQ off on SATA disks before because it was > foiling Linux's I/O priority management, so tasks with low ionice levels > still ended up rather severely impacting system responsiveness. > > Hopefully these devices will end up with the smarts to manage I/O in a > priority queue where read latency is considered as well as throughput. > >> Their answer was something like, "smart disk drives are a relatively >> recent invention." But > > -- > Craig Ringer > Thanks!! Is there a howto somewhere on disabling this on a Seagate Barracuda? I'm in the middle of rebuilding my tools and analysis algorithms as a "real open source project", and I'd love to be able to have some working examples that people without access to industrial strength I/O subsystems can use. :) -- M. Edward (Ed) Borasky I've never met a happy clam. In fact, most of them were pretty steamed. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
