From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suparna Bhattacharya Subject: Re: kjournald() with DIO Date: Thu, 15 Sep 2005 16:41:10 +0530 Message-ID: <20050915111110.GA6904@in.ibm.com> References: <1126567387.14837.36.camel@dyn9047017102.beaverton.ibm.com> <20050912163732.036b2971.akpm@osdl.org> <1126569984.14837.47.camel@dyn9047017102.beaverton.ibm.com> <20050912172935.19907edf.akpm@osdl.org> <1126630370.14837.60.camel@dyn9047017102.beaverton.ibm.com> <20050913160701.355cd46a.akpm@osdl.org> <1126718583.4010.6.camel@localhost.localdomain> <20050914111809.41c5b395.akpm@osdl.org> <1126734025.4010.21.camel@localhost.localdomain> <20050914150224.3b6d7051.akpm@osdl.org> Reply-To: suparna@in.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: cmm@us.ibm.com, pbadari@us.ibm.com, linux-fsdevel@vger.kernel.org, sct@redhat.com, andrea@suse.de Return-path: Received: from e33.co.us.ibm.com ([32.97.110.131]:21388 "EHLO e33.co.us.ibm.com") by vger.kernel.org with ESMTP id S964817AbVIOLDs (ORCPT ); Thu, 15 Sep 2005 07:03:48 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j8FB3L6c286006 for ; Thu, 15 Sep 2005 07:03:22 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8FB240D537670 for ; Thu, 15 Sep 2005 05:02:04 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j8FB23n6023977 for ; Thu, 15 Sep 2005 05:02:03 -0600 To: Andrew Morton Content-Disposition: inline In-Reply-To: <20050914150224.3b6d7051.akpm@osdl.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Sep 14, 2005 at 03:02:24PM -0700, Andrew Morton wrote: > Mingming Cao 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