Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761511AbXJQKb2 (ORCPT ); Wed, 17 Oct 2007 06:31:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753239AbXJQKbS (ORCPT ); Wed, 17 Oct 2007 06:31:18 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:36514 "EHLO ebiederm.dsl.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753176AbXJQKbQ (ORCPT ); Wed, 17 Oct 2007 06:31:16 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Nick Piggin Cc: Andrew Morton , Christian Borntraeger , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Martin Schwidefsky , "Theodore Ts'o" Subject: Re: [patch][rfc] rewrite ramdisk References: <200710151028.34407.borntraeger@de.ibm.com> <200710161808.06405.nickpiggin@yahoo.com.au> <200710161747.12968.nickpiggin@yahoo.com.au> Date: Wed, 17 Oct 2007 04:30:39 -0600 In-Reply-To: <200710161747.12968.nickpiggin@yahoo.com.au> (Nick Piggin's message of "Tue, 16 Oct 2007 17:47:12 +1000") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1740 Lines: 48 Nick Piggin writes: > On Tuesday 16 October 2007 18:08, Nick Piggin wrote: >> On Tuesday 16 October 2007 14:57, Eric W. Biederman wrote: > >> > > What magic restrictions on page allocations? Actually we have >> > > fewer restrictions on page allocations because we can use >> > > highmem! >> > >> > With the proposed rewrite yes. > > Here's a quick first hack... > > Comments? I have beaten my version of this into working shape, and things seem ok. However I'm beginning to think that the real solution is to remove the dependence on buffer heads for caching the disk mapping for data pages, and move the metadata buffer heads off of the block device page cache pages. Although I am just a touch concerned there may be an issue with using filesystem tools while the filesystem is mounted if I move the metadata buffer heads. If we were to move the metadata buffer heads (assuming I haven't missed some weird dependency) then I think there a bunch of weird corner cases that would be simplified. I guess that is where I look next. Oh for what it is worth I took a quick look at fsblock and I don't think struct fsblock makes much sense as a block mapping translation layer for the data path where the current page caches works well. For less then the cost of 1 fsblock I can cache all of the translations for a 1K filesystem on a 4K page. I haven't looked to see if fsblock makes sense to use as a buffer head replacement yet. Anyway off to bed with me. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/