From owner-freebsd-hackers Fri May 7 15:57:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 875D914F5B for ; Fri, 7 May 1999 15:57:04 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id SAA24386; Fri, 7 May 1999 18:18:29 -0500 (EST) Date: Fri, 7 May 1999 18:18:25 -0500 (EST) From: Alfred Perlstein To: Brian Feldman Cc: hackers@FreeBSD.ORG Subject: Re: memory-based VFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 7 May 1999, Brian Feldman wrote: > On Fri, 7 May 1999, Alfred Perlstein wrote: > > > On Fri, 7 May 1999, Chris Costello wrote: > > > > > On Fri, May 7, 1999, Ronald G. Minnich wrote: > > > > The v9fs memory-based VFS, written by Aaron Marks, is available at > > > > http://www.acl.lanl.gov/~rminnich/ > > > > > > Doesn't this do the same thing as MFS? > > > > Yes, but without the mount_mfs process kludge it seems to allow for > > single copy, rather than double copy and extra context switches, it > > uses kvm instead of a user process for backing store. > > So what would be wrong with using a swap-backed vn(4) and newfs/tunefs/ > mounting it? It's a kludge, a MUCH improved kludge, but yet a kludge. You can't for instance... resize the filesystem, it will do FFS-y type things where there is no need to do them, even in async mode. Limits on inodes, limits on block sizes... it could all be changed dynamically with a "real" mfs. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message