maria-discuss team mailing list archive

[Xiaofei Du <xiaofei.du008@xxxxxxxxx>]

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@xxxxxxxxx> wrote:

> Hi Laurynas,
>
> On Wed, May 6, 2015 at 9:14 PM, Laurynas Biveinis <
> laurynas.biveinis@xxxxxxxxx> 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
>>
>
>