Skip site navigation (1) Skip section navigation (2)

Re: O_DIRECT in freebsd

From: Greg Stark <gsstark(at)mit(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: O_DIRECT in freebsd
Date: 2003-10-30 03:56:39
Message-ID: 87ism7fkeg.fsf@stark.dyndns.tv (view raw or flat)
Thread:
Lists: pgsql-hackers
Manfred Spraul <manfred(at)colorfullife(dot)com> writes:

> One problem for WAL is that O_DIRECT would disable the write cache -
> each operation would block until the data arrived on disk, and that might block
> other backends that try to access WALWriteLock.
> Perhaps a dedicated backend that does the writeback could fix that.

aio seems a better fit.

> Has anyone tried to use posix_fadvise for the wal logs?
> http://www.opengroup.org/onlinepubs/007904975/functions/posix_fadvise.html
> 
> Linux supports posix_fadvise, it seems to be part of xopen2k.

Odd, I don't see it anywhere in the kernel. I don't know what syscall it's
using to do this tweaking.

This is the only option that seems useful for postgres for both the WAL and
vacuum (though in other threads it seems the problems with vacuum lie
elsewhere):

       POSIX_FADV_DONTNEED attempts to free cached pages associated with the
       specified region. This is useful, for example, while streaming large
       files. A program may periodically request the kernel to free cached
       data that has already been used, so that more useful cached pages are
       not discarded instead.

       Pages that have not yet been written out will be unaffected, so if the
       application wishes to guarantee that pages will be released, it should
       call fsync or fdatasync first.

Perhaps POSIX_FADV_RANDOM and POSIX_FADV_SEQUENTIAL could be useful in a
backend before starting a sequential scan or index scan, but I kind of doubt
it.

-- 
greg


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2003-10-30 03:58:30
Subject: Re: Fwd: Re: Call for port reports
Previous:From: Philip YarraDate: 2003-10-30 00:30:24
Subject: Fwd: Re: Call for port reports

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group