Re: kjournald() with DIO

[Mingming Cao <cmm@us.ibm.com>]

On Wed, 2005-09-14 at 11:18 -0700, Andrew Morton wrote:
> Mingming Cao <cmm@us.ibm.com> wrote:
> >
> > On Tue, 2005-09-13 at 16:07 -0700, Andrew Morton wrote:
> > 
> > > Or simply ignore the invalidate_inode_pages2_range() return value in
> > > generic_file_direct_IO().
> > > 
> > Could we simply do that?
> > 
> > I found some discussions about why we check the return value of
> > invalidate_inode_pages2_range() in generic_file_direct_IO():
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=109850054025709&w=2
> 
> Well found.  That brings it back.
> 
> > It seems the check for EIO was added to 2.6.11 to handle the case of
> > parallel direct IO and mapped IO. It is possible that the mapped IO
> > dirty the pages after the a_ops->direct_IO.  In that case, an error will
> > return back to the caller of DIO to indicate the race. 
> 
> According to the logic we discussed last year,
> invalidate_inode_pages2_range() only needs to return -EIO if it failed to
> invalidate a page, and that page was dirty.
> 
> The -EIO is there to tell the caller that another process dirtied pagecache
> against the file (within the range of the direct-io write()) after
> generic_file_direct_IO() has synced the pagecache to disk.
> 
> The -EIO is telling the direct-io write()r "hey, the data which you wrote
> was overwritten by a racing buffered-write() or mmapped-write".  It's not
> obvious to me _why_ we should tell the direct-io write()r this - after all,
> we assume that's what the application developer wanted to do.
> 
> Still, we don't have to worry about that at present because
> invalidate_inode_pages2_range() is just doing the wrong thing: it's
> treating this elevated-refcount buffer_head as if it was a dirty page, and
> it's not.
> 
> How about this?

I proposed similar idea to Andrea in the bug report before.  Andrea
expressed this concern: with this(try_to_free_buffers() still fail to
drop the buffer because of this elevated-refcount by kjournald),
block_read_full_page will not re-read from disk the buffers the next
time a buffered-IO read from disk, after the direct-io has completed.
This is because the buffer is marked uptodate. How could we handle this?

Mingming