From owner-freebsd-hackers Thu Jan 7 17:49:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA11095 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 17:49:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA11090 for ; Thu, 7 Jan 1999 17:49:16 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id UAA58709; Thu, 7 Jan 1999 20:52:50 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Thu, 7 Jan 1999 20:52:50 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Terry Lambert cc: Matthew Dillon , dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable In-Reply-To: <199901080044.RAA22486@usr01.primenet.com> 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, 8 Jan 1999, Terry Lambert wrote: > OK, the MFS stuff first. > > > :> on a soft block. For example, UFS/FFS was never designed to terminate > > :> on memory, much less swap-backed memory. Then came along MFS and > > :> suddently were (and still are) all sorts of problems. > > : > > :I'd argue that MFS is an inappropriate use of the UFS code, since the > > :UFS code doesn't acknowledge the idea of shrinking block-backing > > :objects, and barely (with severe fragmentation based degradation) > > :recognizes growing block-backing objects. > > > > I have no idea what you are talking about here. > > I'm saying that the MFS problems you are noting are artifacts of > the implementation, not the idea, and that if you go back to > first principles, and correctly implement the idea, then you > won't have those problems. .... ... .. [snip] MFS is just lazyness, if you want it to grow/work right, you rewrite it instead of hacking FFS on top of it. or you design it in such a way that it's a device that FFS is somewhat aware of. this way when a block is asked to be filled what really happens is that the block passed in is put on the free block list and FFS is given a page of the MFS to use, when FFS pushes the block back to MFS the replaced page is put back under the vnode. MFS then becomes a device instead of a filesystem. although i think it violates some abstraction, does this make sense? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message