(Illustration by Gaich Muramatsu)
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