From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?B?SsO2cm4=?= Engel Subject: Re: PG_updatodate vs BH_updatodate Date: Mon, 24 Nov 2008 16:56:33 +0100 Message-ID: <20081124155633.GB3051@logfs.org> References: <20081123041938.GW3186@webber.adilger.int> <20081123122124.GH5707@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Matthew Wilcox , Andreas Dilger , linux-fsdevel@vger.kernel.org To: Francis Moreau Return-path: Received: from lazybastard.de ([212.112.238.170]:41975 "EHLO longford.logfs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752831AbYKXP4q (ORCPT ); Mon, 24 Nov 2008 10:56:46 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, 23 November 2008 21:14:47 +0100, Francis Moreau wrote: > Matthew Wilcox writes: > > On Sun, Nov 23, 2008 at 01:14:52PM +0100, Francis Moreau wrote: > > > >> Are there any cases where a page can be partially uptodate ? > > > > Consider a filesystem with 1k blocks and a system with a page size = of 4k. > > You have a buffer_head for each of the four blocks that are being k= ept > > in the page, and you want to track their dirty state independently. >=20 > Sorry but I'm confused since you're taking about the dirty state > (tracked by BH_Dirty bit) and I was taking about the uptodate state > (tracked by BH_Uptodate bit). Think page cache, except that the granularity is not pages but 1k blocks. If your filesystem wants to read an indirect block, 1k is read into the cache, the other 3k (or 63k) of the page remain as they were. If you have to cache data on a granularity smaller than a page, as many filesystems, your only alternative would be to leave the remaining 3k (or 63k) empty - a rather wasteful approach. J=C3=B6rn --=20 A surrounded army must be given a way out. -- Sun Tzu -- 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