From owner-freebsd-hackers Tue Jan 5 18:56:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA29694 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 18:56:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id SAA29674 for ; Tue, 5 Jan 1999 18:56:18 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 21466 invoked from network); 6 Jan 1999 02:55:48 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 6 Jan 1999 02:55:48 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id VAA02192; Tue, 5 Jan 1999 21:55:45 -0500 (EST) Message-Id: <199901060255.VAA02192@y.dyson.net> Subject: Re: questions/problems with vm_fault() in Stable In-Reply-To: <199901060044.RAA22046@usr05.primenet.com> from Terry Lambert at "Jan 6, 99 00:44:48 am" To: tlambert@primenet.com (Terry Lambert) Date: Tue, 5 Jan 1999 21:55:45 -0500 (EST) Cc: dillon@apollo.backplane.com, tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert said: > > :I don't really buy this for the general case, which I believe is > > :still stacking layers that don't access local media. > > : > > :For local media FS's, things which actially do I/O through a page > > :fault, this is probably correct. > > > > Ouch.. no, get away from the 'local media' concept - it's a big time > > bust. If you make the distinction between hard media and soft media > > (or local media verses remote media), all you do is screw up the layering > > model. Even now, traditional hard-media-backed VFS layers such as UFS > > can be stacked on top of soft media layers such as MFS, which in turn > > is stacked on top of SWAP (which may be a hard or soft media layer > > itself). If you throw NFS into the fray it gets worse. It just doesn't > > work. Also, these sorts of schemes require both interacting VFS layers > > to have knowledge about each other that goes far beyond what two > > layers ought to know about each other. > > The distinction I'm trying to make is between VFS layers that are VFS > consumers and providers, and VFS layers that that are VFS providers, > but VM system consumers. VM system consumers are "local media" FS's. > The VM system is a provider :-). The VFS provides only the file naming abstraction. > > The problem is in ensuring object coherency. Here we have this > enormous investment in a unified VM and buffer cache, which is mostly > just a way for us to avoid the coherency complications that having > seperate VM and buffer cache cause, and we're talking about doing > something that will reintroduce the complications. > Please look at the ideas again -- using the VM mechanisms for layering eliminate the IMPOSSIBILITY for a VFS layering scheme (as it currently is in any fashion) to provide coherence. A bidirectional object oriented scheme can easily provide coherence. Tell me, what protocol exists (or can exist) in the current VFS framework to provide coherence for mmap, or file I/O with different layers? Answer: none. Thinking of things as files begs the fact that files are all a specific instance of a memory object, let's forget about "files" and local filesystems. (I guess that it is possible for a VFS to provide coherence, at the expense of continual "sync" operations -- that is just wrong.) Think in terms of "stuff" or "objects." The only way that coherence can work in the current framework is in the non-layered and/or local case. If you get much beyond the typical filesystem structure, then problems start arising, and hacks tend to be the expedient solution. Rather than fight an existing structure, it seems that the correct thing is to rethink the structure that can architecturally provide the features needed and desired -- without hackery and special rules. > > Maybe I'm coming in in the middle of a long private discussion (it > feels like it, and Julian has hinted that I am), but I think that > its necessary to fix some of the things we all know are broken > before we try to get tricky... my 2 cents. > The problem with the VFS is that it doesn't appear to be possible to fully fix it given the goal of coherent layering. There is no sane way that a lower layer invalidation can properly propagate upwards to other consumers without treating the data (or objects) with a proper invalidation protocol. Any of the problems with the existing VFS/VM scheme have been with the intricacies of dealing with VFS special cases, and dealing with the I/O abstraction of buffers as a cache. Forget "files" and think "blobs of memory." Once the notion of file is forgotten, then shadowing, invalidation and aliasing of memory become very obvious... I wouldn't really care if the new scheme would be called "VFS", but forget vnodes and bp's... They are unnecessary and undesirable abstractions except at the lowest layers (the leaf filesystems that have those legacy concepts.) -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message