From owner-freebsd-current Fri Aug 28 20:20:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA04668 for freebsd-current-outgoing; Fri, 28 Aug 1998 20:20:20 -0700 (PDT) (envelope-from owner-freebsd-current@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 UAA04662 for ; Fri, 28 Aug 1998 20:20:17 -0700 (PDT) (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 DAA15630; Sat, 29 Aug 1998 03:17:39 GMT Date: Sat, 29 Aug 1998 12:17:38 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: Mike Smith , julian@whistle.com, abial@nask.pl, freebsd-current@FreeBSD.ORG Subject: Re: It's MFS panic.. (Re: Panic with DEVFS) In-Reply-To: <199808290152.SAA00390@usr01.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 29 Aug 1998, Terry Lambert wrote: > I would recommend reimplementing this with a "Memory device" driver, > and putting your standard FS on the thing, instead. At best, you > would end up with unallocated pages (a "sparse" device), and at worst, > the overhead can't be more than mfs->specfs->strategy->mfs->specfs->mfs. I think NetBSD has a memory disk device. I still think fronting anonymous memory is pretty cool though, but I'd like to see it done with data structures that make make sense for memory rather than using code from ufs. It would be much easier to implement a system that can grow and shrink its usage of resources than the RAM disk approach because it competes for pages like any other process. Having both of the above would be ok too. :-) Regards, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message