Jan, Laurynas,

Thank you both for your helpful answers. The general question I have is that do we need to call fsync to guarantee a dirty page is written to persistent storage before it's removed from the flush list, and how would this affect the recovery process? Based on the code, looks like it does not call fsync before buf_flush_write_complete is called. So I guess not calling fsync will not affect recovery process. But I also saw fsync is called after synchronous IOs. So I am confused about if we should call fsync or not after flushing a dirty page in order to not break recovery. Thanks.

Xiaofei

On Wed, May 6, 2015 at 11:01 PM, Xiaofei Du <xiaofei.du008@gmail.com> wrote:

Hi Laurynas,

On Wed, May 6, 2015 at 9:14 PM, Laurynas Biveinis <laurynas.biveinis@gmail.com> wrote:
Xiaofei -

> Does InnoDB maintain a dirty
> page table?

You must be referring to the buffer pool flush_list.

You are right. The flush_list is can be used for recovery and checkpoint.

> Is fsync called to guarantee the page to be on persistent
> storage so that the dirty page table can be updated? If this is the case,
> when is the dirty page table updated for asynchronous IOs?

Check buf_flush_write_complete in buf0flu.cc. For async IO it is
called from buf_page_io_complete in buf0buf.cc.

You are right that this is the place it updates the dirty page information. But I still don't understand why the fsync is needed for synchronous IOs, but not for the AIOs. Jan Lindstrom said fsync is also called for other AIO operations. But I could only it true in one of many AIO operations. Or maybe I am missing something still?

--
Laurynas