On Tue, Sep 20, 2011 at 11:03 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> I don't see what difference it makes which process does the I/O. If a
>> write() by checkpointer process blocks, any write()s by the separate
>> bgwriter process at that time will block too. If the I/O is not saturated,
>> and the checkpoint write()s don't block, then even without this patch, the
>> bgwriter process can handle its usual bgwriter duties during checkpoint just
>> fine. (And if the I/O is not saturated, it's not an I/O bound system
>> anyway.)
>
> Whatever value you assign to the bgwriter, then this patch makes sure
> that happens during heavy fsyncs.
I think his point is that it doesn't because if the heavy fsyncs cause
the system to be i/o bound it then bgwriter will just block issuing
the writes instead of the fsyncs.
I'm not actually convinced. Writes will only block if the kernel
decides to block. We don't really know how the kernel makes this
decision but it's entirely possible that having pending physical i/o
issued due to an fsync doesn't influence the decision if there is
still a reasonable number of dirty pages in the buffer cache. In a
sense, "I/O bound" means different things for write and fsync. Or to
put it another way fsync is latency sensitive but write is only
bandwidth sensitive.
All that said my question is which way is the code more legible and
easier to follow?