From owner-freebsd-fs Tue Mar 17 00:56:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA03675 for freebsd-fs-outgoing; Tue, 17 Mar 1998 00:56:59 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA03670 for ; Tue, 17 Mar 1998 00:56:55 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id IAA10720; Tue, 17 Mar 1998 08:53:59 GMT Date: Tue, 17 Mar 1998 17:53:58 +0900 (JST) From: Michael Hancock To: Chris Csanady cc: Wolfram Schneider , Joao Carlos Mendes Luis , fs@FreeBSD.ORG Subject: Re: cvs commit: src/usr.bin/locate/locate concatdb.sh locate.rc mklocatedb.sh updatedb.sh In-Reply-To: <199803141419.IAA06967@friley585.res.iastate.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 14 Mar 1998, Chris Csanady wrote: > >If we have a working memory file system I will revert this > >change. The main problem is that the process mount_mfs(8) > >will only grow and never shrink. > > Has anyone looked at NetBSD's md pseudo-device? It provides a generic > memory disk which you can put an arbitrary file system onto. Seems to > me that it would be better than using a hacked up ffs.. A ram disk would be ok, but it would also be nice to have a memfs that could have it's pages swapped out like mfs and not having to decide the size of the disk in advance. Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message