Re: a question about Direct I/O and double buffering - Mailing list pgsql-performance

From david@lang.hm
Subject Re: a question about Direct I/O and double buffering
Date
Msg-id Pine.LNX.4.64.0704051832130.28411@asgard.lang.hm
Whole thread Raw
In response to Re: a question about Direct I/O and double buffering  (Xiaoning Ding <dingxn@cse.ohio-state.edu>)
List pgsql-performance
On Thu, 5 Apr 2007, Xiaoning Ding wrote:

>> >  Xiaoning
>> >  Looks like it.  I just did a cursory search of the archives and it seems
>> >  that others have looked at this before so you'll probably want to start
>> >  there if your up to it.
>> >
>>
>>  Linux used to have (still does?) a RAW interface which might also be
>>  useful.  I think the original code was contributed by oracle so they
>>  could support direct IO.
>>
>>  Alex
> I am more concerned with reads , and how to do direct I/O under Linux here.
> Reading raw devices in linux bypasses OS buffer cache.

it also bypassed OS readahead, not nessasarily a win

>  But how can you
> mount a raw device( it is a character device) as a file system?

you can do a makefs on /dev/hda just like you do on /dev/hda2 and then
mount the result as a filesystem.

Postgres wants the OS layer to provide the filesystem, Oracle implements
it's own filesystem, so you would just point it at the drive/partition and
it would do it's own 'formatting'

this is something that may be reasonable for postgres to consider doing
someday, since postgres allocates things into 1m files and then keeps
track of what filename is used for what, it could instead allocate things
in 1m (or whatever size) chunks on the disk, and just keep track of what
addresses are used for what instead of filenames. this would definantly
allow you to work around problems like the ext2/3 indirect lookup
problems. now that the ability for partitioned table spaces it would be an
interesting experiment to be able to define a tablespace that used a raw
device instead of a filesystem to see if there are any noticable
performance gains

David Lang

pgsql-performance by date:

Previous
From: Vincenzo Romano
Date:
Subject: Re: Weird performance drop
Next
From: david@lang.hm
Date:
Subject: Re: SCSI vs SATA