From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Brown Subject: Re: vm/fs meetup details Date: Sat, 7 Jul 2007 09:47:11 +1000 Message-ID: <18062.54399.299212.286138@notabene.brown> References: <468D303E.4040902@redhat.com> <137D15F6-EABE-4EC1-A3AF-DAB0A22CF4E3@oracle.com> <20070705212757.GB12413810@sgi.com> <468D6569.6050606@redhat.com> <20070706022651.GG14215@wotan.suse.de> <20070706100110.GD12413810@sgi.com> <20070706102623.GA846@lazybastard.org> <20070706134201.GL31489@sgi.com> <20070706095214.1ac9da94@think.oraclecorp.com> <20070706155748.GC846@lazybastard.org> <20070706155803.GA31405@fogou.chygwyn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: =?iso-8859-1?Q?J=F6rn?= Engel , Chris Mason , David Chinner , Nick Piggin , Rik van Riel , Zach Brown , Anton Altaparmakov , Suparna Bhattacharya , Christoph Hellwig , Hugh Dickins , Jared Hulbert , "Martin J. Bligh" , Trond Myklebust , Miklos Szeredi , Mingming Cao , Linux Memory Management List , linux-fsdevel@vger.kernel.org, Evgeniy Polyakov , Dave McCracken , Peter Zijlstra To: Steven Whitehouse Return-path: Received: from mx1.suse.de ([195.135.220.2]:58043 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752041AbXGFXsE convert rfc822-to-8bit (ORCPT ); Fri, 6 Jul 2007 19:48:04 -0400 In-Reply-To: message from Steven Whitehouse on Friday July 6 Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Friday July 6, steve@chygwyn.com wrote: > Hi, >=20 > On Fri, Jul 06, 2007 at 05:57:49PM +0200, J=F6rn Engel wrote: =2E.. > >=20 > > Interesting idea. Is it possible to attach several address spaces = to an > > inode? That would cure some headaches. > > > GFS2 already uses something like this, in fact by having a second ino= de > to contain the second address space. Thats a bit of a hack but we can= 't =2E.. >=20 > So that would certainly be an issue that I'd like to discuss to see > what can be worked out in that area, >=20 > Steve. Maybe the question here is: What support should common code provide for caching indexing metadata? Common code already provides the page cache that is very nice for caching file data. Some filesystems use the blockdev page cache to cache index metadata by physical address. But I think that increasingly filesystems want to cache index metadata by some sort of virtual address. A second page cache address space would be suitable if the addresses were dense, and would be acceptable if the blocks were page-sized (or larger). But for non-dense, non-page-sized blocks, a radix tree of pages is less than ideal (I think). My filesystem (LaFS, which is actually beginning to work thanks to Novell's HackWeek) uses non-dense, non-page-sized blocks both for file indexing and for directories and while I have a working solution for each case, there is room for improvements that might fit well with other filesystems too. NeilBrown - 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