Re: kjournald() with DIO

[Andrew Morton <akpm@osdl.org>]

Andrea Arcangeli <andrea@suse.de> wrote:
>
> On Thu, Sep 15, 2005 at 01:35:00PM -0700, Andrew Morton wrote:
> > I'll need reminding - why was the buffer unfreeable?  Because kjournald had
> > a ref on it?  Whereabouts is that happening?
> 
> Yes, kjournald had a ref (b_count) on it. It's happening when running
> iozone in some way (Badari knows how to reproduce).
> 
> I was now wondering why it's a problem to destroy dirty buffers in
> invalidate_inode_pages2? (ok, ignoring the detail that PageDirty may
> return true inside invalidate_complete_page)

Bear in mind that generic_file_direct_IO() has just fsynced that section of
the file so there shouldn't be any dirty buffers unless something funny is
happening.  Like, direct-io fell back to buffered IO.  In that case perhaps
we should run sync_page_range() before trying the
invalidate_inode_pages2_range()?

> Clearly we can't do that inside releasepage, but invalidate_inode_pages2
> is all about destroying the dirty and uptodate information, since we
> just finished writing with direct-io (or at least the dirty info isn't
> that important anymore, we're still in our write context for those pages
> that we're invalidating [even better with the range]).

Those dirty pages/buffers could be there because
__generic_file_aio_write_nolock() fell back to buffered I/O.

If we run sync_page_range() before invalidate_inode_pages2_range() and we
*still* find dirty pages/buffers then yes, it might be right to simply nuke
those dirty bits.