Re: a question about Direct I/O and double buffering

On Thu, 5 Apr 2007, Xiaoning Ding wrote:

>>
>> To the best of my knowledge, Postgres itself does not have a direct IO
>> option (although it would be a good addition). So, in order to use direct
>> IO with postgres you'll need to consult your filesystem docs for how to
>> set the forcedirectio mount option. I believe it can be set dynamically,
>> but if you want it to be permanent you'll to add it to your fstab/vfstab
>> file.
>
> I use Linux. It supports direct I/O on a per-file basis only. To bypass OS
> buffer cache,
> files should be opened with O_DIRECT option. I afraid that I have to modify
> PG.

as someone who has been reading the linux-kernel mailing list for 10
years, let me comment on this a bit.

linux does have a direct i/o option, but it has significant limits on when
and how you cna use it (buffers must be 512byte aligned and multiples of
512 bytes, things like that). Also, in many cases testing has shon that
there is a fairly significant performance hit for this, not a perfomance
gain.

what I think that postgres really needs is to add support for write
barriers (telling the OS to make shure that everything before the barrier
is written to disk before anything after the barrier) I beleive that these
are avaiable on SCSI drives, and on some SATA drives. this sort of
support, along with appropriate async I/O support (which is probably going
to end up being the 'syslets' or 'threadlets' stuff that's in the early
experimental stage, rather then the current aio API) has the potential to
be a noticable improvement.

if you haven't followed the syslets discussion on the kernel list,
threadlets are an approach that basicly lets you turn any syscall into a
async interface (if the call doesn't block on anything you get the answer
back immediatly, if it does block it gets turned into a async call by the
kernel)

syslets are a way to combine multiple syscalls into a single call,
avoiding the user->system->user calling overhead for the additional calls.
(it's also viewed as a way to do prototyping of possible new calls, if a
sequence of syscalls end up being common enough the kernel devs will look
at makeing a new, combined, syscall (for example lock, write, unlock could
be made into one if it's common enough and there's enough of a performance
gain)

David Lang