Re: kjournald() with DIO

[Suparna Bhattacharya <suparna@in.ibm.com>]

On Wed, Sep 14, 2005 at 03:02:24PM -0700, Andrew Morton wrote:
> Mingming Cao <cmm@us.ibm.com> wrote:
> >
> > 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?
> 
> Well.  Application A has written data x with direct-io.  Application B has,
> at a later time, written, dirtied (or even read) data y with buffered I/O.

I guess the concern is the the page that B has written was based off stale
data, which has been mmap written with a few new bytes.

But I wonder, do we really have to or intend to guarantee DIO vs mmaped
write consistency ? What we have is sort of best effort -- we just ensure
no corruptions and exposures, and try to keep data consistent to the
extent we can. Can we actually do a perfect job ?

> 
> So the contents of pagecache are in fact correct, but it is not known
> whether or not the data on disk is correct.
> 
> I guess one way of resolving it is to make invalidate_inode_pages2_range()
> provide a hard guarantee: call truncate_complete_page() instead of
> invalidate_complete_page().  We need to have a think about the implications
> of that.  For starters, if someone gets in at the right time and
> reinstantiates a pte against the page, we'll end up converting that into an
> anonymous page.


Regards
Suparna

> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Suparna Bhattacharya (suparna@in.ibm.com)
Linux Technology Center
IBM Software Lab, India