Drives have their own read-ahead in the firmware. Many can keep track of 2 or 4 concurrent file accesses. A few can keep track of more. This also plays in with the NCQ or SCSI command queuing implementation.
Consumer drives will often read-ahead much more than server drives optimized for i/o per second. The difference in read-ahead sensitivity between the two setups I tested may be due to one setup using nearline-SAS (SATA, tuned for io-per sec using SAS firmware) and the other used consumer SATA. For example, here is one "nearline SAS" style server tuned drive versus a consumer tuned one: http://www.storagereview.com/php/benchmark/suite_v4.php?typeID=10&testbedID=4&osID=6&raidconfigID=1&numDrives=1&devID_0=354&devID_1=348&devCnt=2 The Linux readahead setting is _definitely_ in the kernel, definitely uses and fills the page cache, and from what I can gather, simply issues extra I/O's to the hardware beyond the last one requested by an app in certain situations. It does not make your I/O request larger, it just queues an extra I/O following your request. On Thu, Sep 11, 2008 at 12:54 PM, James Mansion < [EMAIL PROTECTED]> wrote: > Greg Smith wrote: > >> The point I was trying to make there is that even under impossibly optimal >> circumstances, you'd be hard pressed to blow out the disk's read cache with >> seek-dominated data even if you read a lot at each seek point. That idea >> didn't make it from my head into writing very well though. >> >> Isn't there a bigger danger in blowing out the cache on the controller > and causing premature pageout of its dirty pages? > > If you could get the readahead to work on the drive and not return data to > the controller, that might be dandy, but I'm sceptical. > > James > > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance >
