From mboxrd@z Thu Jan 1 00:00:00 1970 From: Badari Pulavarty Subject: Re: kjournald() with DIO Date: Thu, 15 Sep 2005 08:03:23 -0700 Message-ID: <1126796604.14837.111.camel@dyn9047017102.beaverton.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> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: cmm@us.ibm.com, linux-fsdevel@vger.kernel.org, sct@redhat.com, andrea@suse.de Return-path: Received: from e35.co.us.ibm.com ([32.97.110.133]:37322 "EHLO e35.co.us.ibm.com") by vger.kernel.org with ESMTP id S1030488AbVIOPEL (ORCPT ); Thu, 15 Sep 2005 11:04:11 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j8FF3tLZ336394 for ; Thu, 15 Sep 2005 11:03:58 -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 j8FF3qab290732 for ; Thu, 15 Sep 2005 09:03:52 -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 j8FF3pTq016706 for ; Thu, 15 Sep 2005 09:03:51 -0600 To: Andrew Morton In-Reply-To: <20050914150224.3b6d7051.akpm@osdl.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 2005-09-14 at 15:02 -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. > > 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. FWIW, I changed it to call truncate_complete_page() and the tests ran fine overnight. Thanks, Badari