Date: Wed, 6 Jan 1999 00:44:48 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Message-ID: <199901060044.RAA22046@usr05.primenet.com> In-Reply-To: <199901052308.PAA98255@apollo.backplane.com> from "Matthew Dillon" at Jan 5, 99 03:08:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> :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. As soon as VFS stacking finally works in the main line FreeBSD, I expect the VFS provider and consumer layers to literally explode through the roof. Because of this, I think it's necessary to think in terms of abstracting the VM complications as much as possible. I have a real problem with the idea of VM alias objects instead of a mechanism for asking for the vnode off of which is hung the real backing object so that I can forwar VOP_GETPAGE/VOP_PUTPAGES against it. 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. Right now there's some obvious problems; the point of an msync() is to ensure that the buffer cache and the VM are coherent. In theory, a unified VM and buffer cache doesn't need an msync() call at all, right? Yet INN fails under FreeBSD in the file extension case unless you insert an msync() call. Yeah, you should expect to have to msync() in an SVR4 environment, and in OpenBSD and maybe NetBSD (current UVM code), but FreeBSD isn't supposed to need this. Yet it does. If a coherency problem must be solved by an explicit call to notify the OS of a boundary crossing condition, then there is a unification error, plain and simple. I think that introducing an alias object is a mistake. It's possible to get an alias object implementation correct, if you are very, very careful in your implementation. But the same can be said about mmap() coherency, and I'm not bold enough to believe that I'm the guy who saw the last problem in that area. 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. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901060044.RAA22046>