From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754801AbXDZNxG (ORCPT ); Thu, 26 Apr 2007 09:53:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754798AbXDZNxG (ORCPT ); Thu, 26 Apr 2007 09:53:06 -0400 Received: from il.qumranet.com ([82.166.9.18]:46952 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754801AbXDZNxF (ORCPT ); Thu, 26 Apr 2007 09:53:05 -0400 Message-ID: <4630AEBC.4000002@argo.co.il> Date: Thu, 26 Apr 2007 16:53:00 +0300 From: Avi Kivity User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: David Chinner CC: Nick Piggin , Christoph Lameter , "Eric W. Biederman" , linux-kernel@vger.kernel.org, Mel Gorman , William Lee Irwin III , Jens Axboe , Badari Pulavarty , Maxim Levitsky Subject: Re: [00/17] Large Blocksize Support V3 References: <463048FE.5000600@yahoo.com.au> <46304D50.1040706@yahoo.com.au> <46305327.2000206@yahoo.com.au> <4630593C.8070905@yahoo.com.au> <20070426092014.GT65285596@melbourne.sgi.com> In-Reply-To: <20070426092014.GT65285596@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org David Chinner wrote: > On Thu, Apr 26, 2007 at 05:48:12PM +1000, Nick Piggin wrote: > >> Christoph Lameter wrote: >> >>> On Thu, 26 Apr 2007, Nick Piggin wrote: >>> >>> >>> >>>> No I don't want to add another fs layer. >>>> >>> Well maybe you could explain what you want. Preferably without redefining >>> the established terms? >>> >> Support for larger buffers than page cache pages. >> > > The problem with this approach is that it turns around the whole > way we look at bufferheads. Right now we have well defined 1:n > mapping of page to bufferheads and so we tpyically lock the > page first them iterate all the bufferheads on the page. > > Going the other way, we need to support m:n which we means > the buffer has to become the primary interface for the filesystem > to the page cache. i.e. we need to lock the bufferhead first, then > iterate all the pages on it. This is messy because the cache indexes > via pages, not bufferheads. hence a buffer needs to point to all the > pages in it explicitly, and this leads to interesting issues with > locking. > Why is it necessary to assume that one filesystem block == one buffer? Is it for atomicity, efficiency, or something else? -- error compiling committee.c: too many arguments to function