Coda File System

[dhowells@redhat.com: [PATCH] CacheFS - general filesystem cache]

From: Troy Benjegerdes <hozer_at_hozed.org>
Date: Tue, 31 Aug 2004 14:02:40 -0500
I noticed this on linux-kernel, and it looks very interesting... what
does anyone think of the idea of trying to use cacheFS for the coda
cache backing store? 

It would probably require some changes to the linux venus->kernel
inteface, which opens up questions of would we really want to support a
'special' interface for linux. Any comments?


Delivered-To: hozer_at_hozed.org
Return-Path: <linux-kernel-owner+hozer=40hozed.org-S269822AbUH0Aa0_at_vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org [::ffff:12.107.209.244])
  by kalmia.hozed.org with esmtp; Thu, 26 Aug 2004 19:35:10 -0500
Received: (majordomo_at_vger.kernel.org) by vger.kernel.org via listexpand
	id S269822AbUH0Aa0 (ORCPT <rfc822;hozer_at_hozed.org>);
	Thu, 26 Aug 2004 20:30:26 -0400
Received: (majordomo_at_vger.kernel.org) by vger.kernel.org id S269795AbUH0A3m
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 26 Aug 2004 20:29:42 -0400
Received: from mx1.redhat.com ([66.187.233.31]:28838 "EHLO mx1.redhat.com")
	by vger.kernel.org with ESMTP id S269823AbUH0AXU (ORCPT
	<rfc822;linux-kernel_at_vger.kernel.org>);
	Thu, 26 Aug 2004 20:23:20 -0400
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7R0N6S0025019;
	Thu, 26 Aug 2004 20:23:06 -0400
Received: from warthog.cambridge.redhat.com (warthog.cambridge.redhat.com [172.16.18.73])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7R0N5304436;
	Thu, 26 Aug 2004 20:23:05 -0400
Received: from warthog.cambridge.redhat.com (localhost.localdomain [127.0.0.1])
	by warthog.cambridge.redhat.com (8.12.11/8.12.8) with ESMTP id i7R0N4JE017782;
	Fri, 27 Aug 2004 01:23:04 +0100
Received: from redhat.com (dhowells_at_localhost)
	by warthog.cambridge.redhat.com (8.12.11/8.12.11/Submit) with ESMTP id i7R0N3Jp017778;
	Fri, 27 Aug 2004 01:23:03 +0100
X-Authentication-Warning: warthog.cambridge.redhat.com: dhowells owned process doing -bs
From: David Howells <dhowells_at_redhat.com>
To: torvalds_at_osdl.org, akpm_at_osdl.org
cc: linux-kernel_at_vger.kernel.org, steved_at_redhat.com, dwmw2_at_redhat.com
Subject: [PATCH] CacheFS - general filesystem cache
User-Agent: EMH/1.14.1 SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Fri, 27 Aug 2004 01:23:03 +0100
Message-ID: <17777.1093566183_at_redhat.com>
Sender: linux-kernel-owner_at_vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel_at_vger.kernel.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on kalmia.hozed.org
X-Spam-Level: 
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no 
	version=2.63


Hi Linus, Andrew,

I've packaged my generic filesystem cache filesystem into patches and also
produced patches for my AFS filesystem to use it. Work is also in progress to
alter the NFS client use this interface too, and I think the ISO9660
filesystem could also benefit.

I've put a tarball of them on my Red Hat webpage because one of them is rather
large. If you grab:

	http://people.redhat.com/~dhowells/cachefs/cachefs-patches.tar.bz2

You'll find the following patches contained therein:

    (1) cachefs-nullfileptr-2681mm4.diff

	Fix a bug introduced into do_generic_mapping_read() by which a file
	pointer becomes required. I had arranged things so that it was
	optional so that I could call it directly on an inode.

    (2) cachefs-rastateinit-2681mm4.diff

	Revert the change made to file_ra_state_init() that removed the symbol
	export that I'd put in, and also make it fully initialise the state
	again.

	This was also done so that do_generic_mapping_read() could be called
	directly on an inode.

    (3) cachefs-fs-2681mm4.diff

	The cachefs filesystem source and interface header file.

    (4) cachefs-doc-2681mm4.diff

	Documentation about using cachefs.

    (5) cachefs-wppageop-2681mm4.diff

	Add a notification operation to the address space that gets invoked
	when a read-only protected page is about to be made writable. I've
	shown this to Rik van Riel who seems happy with it.

	Using a combination of (5) and (6), I can have cachefs write a netfs
	page into the cache in the background whilst the netfs readpage
	completes and passes the now unlocked page back to userspace.

	Previously, the netfs readpage function had to be synchronous with
	respect to writing the page to disc. Now it can use this callback and
	prepare_write() to synchronise upon the page being modified in the
	page cache before it gets DMA'd to cachefs's disc block.

	David Woodhouse is also interested in using this to do lazy
	reservations in JFFS2 shared writable mapping support.

    (6) cachefs-fspagesync-2681mm4.diff

	This adds another page flag for intra-filesystem synchronisation, to
	operate in a manner similar to PG_writeback.

	I've made my AFS client use this to indicate that a page has now been
	written to the backing cache and can now be safely modified.

    (7) cachefs-afs-2681mm4.diff

	This changes my AFS client so that it can make use of cachefs.

Signed-Off-By: David Howells <dhowells_at_redhat.com>

I've also put a utility on my webpage for dumping the cachefs update journal
contents:

	http://people.redhat.com/~dhowells/cachefs/dump-journal.c

It just needs the fs/cachefs/cachefs-int.h header file placing in the same
directory to compile.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo_at_vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Received on 2004-08-31 15:04:43