Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267444AbTBKKpz>; Tue, 11 Feb 2003 05:45:55 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267473AbTBKKpz>; Tue, 11 Feb 2003 05:45:55 -0500
Received: from [213.86.99.237] ([213.86.99.237]:42720 "EHLO
	warthog.cambridge.redhat.com") by vger.kernel.org with ESMTP
	id <S267444AbTBKKpx>; Tue, 11 Feb 2003 05:45:53 -0500
To: Andrew Morton <akpm@digeo.com>
cc: David Howells <dhowells@redhat.com>, torvalds@transmeta.com,
       jgarzik@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: extra PG_* bits for page->flags 
In-Reply-To: <20030210151244.7e42d3fb.akpm@digeo.com> 
User-Agent: EMH/1.14.1 SEMI/1.14.4 (Hosorogi) FLIM/1.14.4
 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2
 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi")
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 11 Feb 2003 10:54:44 +0000
Message-ID: <29267.1044960884@warthog.cambridge.redhat.com>
From: David Howells <dhowells@warthog.cambridge.redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1349
Lines: 31


Andrew Morton <akpm@digeo.com> wrote:

> > I'm writing a cache filesystem for primarily for caching AFS pages, but
> > that also can be used for caching other network FS pages (such as NFSv4,
> > which Jeff Garzik and Trond Myklebust are interested in, I think).
> 
> Is a new fs needed?  Is it not possible to use an existing filesystem of the
> user's choice for local caching?

The problem with that is who owns the pages being served? With an existing
filesystem either the pages have to belong to the cache FS (and not the net
FS) or double buffering has to be incurred.

What my FS strives to do is make it so the pages are owned by the net FS, the
cache FS just provides operations to perform reads/writes from/to disc to any
page (plus journalling).

The cache FS then only owns the pages which hold its metadata.

Also - though their may be ways around this according to Stephen Tweedie - the
handling of holes in files is different. In my cache FS, a hole as a page that
we don't have from the server yet. In an existing FS, a hole is a page of
zeros that simply doesn't reside on disc.

David
-
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/