Re: vm/fs meetup details

[Neil Brown <neilb@suse.de>]

On Friday July 6, steve@chygwyn.com wrote:
> Hi,
> 
> On Fri, Jul 06, 2007 at 05:57:49PM +0200, Jörn Engel wrote:
...
> > 
> > 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 inode
> to contain the second address space. Thats a bit of a hack but we can't
...
> 
> So that would certainly be an issue that I'd like to discuss to see
> what can be worked out in that area,
> 
> 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