From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 11 Feb 2003 05:57:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 11 Feb 2003 05:57:19 -0500 Received: from [213.86.99.237] ([213.86.99.237]:51168 "EHLO warthog.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Tue, 11 Feb 2003 05:56:26 -0500 To: Valdis.Kletnieks@vt.edu cc: Andrew Morton , David Howells , torvalds@transmeta.com, jgarzik@redhat.com, linux-kernel@vger.kernel.org Subject: Re: extra PG_* bits for page->flags In-Reply-To: <200302110418.h1B4I5jB002548@turing-police.cc.vt.edu> 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 11:05:18 +0000 Message-ID: <29336.1044961518@warthog.cambridge.redhat.com> From: David Howells Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Valdis.Kletnieks@vt.edu wrote: > > Is a new fs needed? Is it not possible to use an existing filesystem of > > the user's choice for local caching? > > It's sort of like a loopback mount - you need a backing store which could be > on an ext3 or ramfs or whatever, and you need the user-visible front end > side of things, which manages the backing store and fetches blocks from > AFS/NFS/etc. Sort of, yes. Making it a filesystem is more a way of making it possible for the kernel to associate a block device directly with the caching code. Rather than adding an additional kernel interface beyond mount/swapon, you can just use mount to add a block device to the cache. Furthermore, it meand that I can provide virtual files along the lines of /proc in the mountpoint that allow you to access status information, and maybe also control the data cached. David