Re: [PERFORM] Effects of setting linux block device readahead size

On Fri, 12 Sep 2008, James Mansion wrote:

> Scott Carey wrote:
>> Consumer drives will often read-ahead much more than server drives
>> optimized for i/o per second.
> ...
>> 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.
> So ... fiddling with settings in Linux is going to force read-ahead, but the
> read-ahead data will hit the controller cache and the system buffers.
>
> And the drives use their caches for cyclinder caching implicitly (maybe the
> SATA drives appear to preread more because the storage density per cylinder
> is higher?)..
>
> But is there any way for an OS or application to (portably) ask SATA, SAS or
> SCSI drives to read ahead more (or less) than their default and NOT return
> the data to the controller?
>
> I've never heard of such a thing, but I'm no expert in the command sets for
> any of this stuff.

I'm pretty sure that's not possible. the OS isn't supposed to even know
the internals of the drive.

David Lang

> James
>
>>
>> On Thu, Sep 11, 2008 at 12:54 PM, James Mansion
>> <james@mansionfamily.plus.com <mailto:james@mansionfamily.plus.com>> 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
>> <mailto:pgsql-performance@postgresql.org>)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-performance
>>
>>
>
>
>

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance