Rob Wultsch wrote:
> Forgive me, but is all of this a step on the slippery slope to
> direct io? And is this a bad thing
I don't really think so. There's an important difference in my head
between direct I/O, where the kernel is told "write this immediately!",
and what I'm trying to achive. I want to give the kernel an opportunity
to write blocks out in an efficient way, so that it can take advantage
of elevator sorting, write combining, and similar tricks. But,
eventually, those writes have to make it out to disk. Linux claims to
have concepts like a "deadline" for I/O to happen, but they turn out to
not be so effective once the system gets backed up with enough writes.
Since fsync time is the only effective deadline, I'm progressing from
the standpoint that adjusting when it happens relative to the write will
help, while still allowing the kernel an opportunity to get the writes
out on its own schedule.
When ends up happening if you push toward fully sync I/O is the design
you see in some other databases, where you need multiple writer
processes. Then requests for new pages can continue to allocate as
needed, while keeping any one write from blocking things. That's one
sort of a way to simulate asynchronous I/O, and you can substitute true
async I/O instead in many of those implementations. We didn't have much
luck with portability on async I/O when that was last experimented with,
and having multiple background writer processes seems like overkill;
that whole direction worries me.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us