Re: [PATCH linux-2.6.0-test10-mm1] filemap_fdatawait.patch

[Janet Morgan <janetmor@us.ibm.com>]

Daniel McNeil wrote:

>On Tue, 2003-12-16 at 18:03, Andrew Morton wrote:
>
>>Daniel McNeil <daniel@osdl.org> wrote:
>>
>>>I have found something else that might be causing the problem.
>>>filemap_fdatawait() skips pages that are not marked PG_writeback.
>>>However, when a page is going to be written, PG_dirty is cleared
>>>before PG_writeback is set (while the PG_locked is set).  So it
>>>looks like filemap_fdatawait() can see a page just before it is
>>>going to be written and not wait for it.  Here is a patch that
>>>makes filemap_fdatawait() wait for locked pages as well to make
>>>sure it does not missed any pages.
>>>
>>This filemap_fdatawait() behaviour is as-designed.  That function is only
>>responsible for waiting on I/O which was initiated prior to it being
>>invoked.  Because it is designed for fsync(), fdatasync(), O_SYNC, msync(),
>>sync(), etc.
>>
>>Now, it could be that this behaviour is not appropriate for the O_DIRECT
>>sync function - the result of your testing will be interesting.
>>
>
>My tests still failed overnight.  I was thinking that maybe a
>non-blocking do_writepages() was happening at the same time as
>the filemap_fdatawrite()/filemap_fdatawait(), so even though the
>page was dirty before the filemap_fdatawrite(), it was missed.
>
>Daniel
>
>
I'm wondering if processing in generic_file_direct_IO() shouldn't look 
more like
sys_fsync()?  When I add to generic_file_direct_IO() a call to 
f_op->fsync() between the calls to filemap_fdatawrite() and 
filemap_fdatawait(), the test Daniel and I have been running no longer 
fails for me.  This change would also seem consistent with 2.4, but I 
could be way off base.

-Janet