Date: Tue, 5 Jan 1999 17:05:07 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: tlambert@primenet.com (Terry Lambert) Cc: dyson@iquest.net, tlambert@primenet.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Message-ID: <199901052205.RAA01732@y.dyson.net> In-Reply-To: <199901051847.LAA10199@usr02.primenet.com> from Terry Lambert at "Jan 5, 99 06:47:29 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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. > Actually, the VM approach works really well for non-local filesystems also. How do you pass a bp or vp around across systems??? Hmmm??? The VM object abstraction simply names data, and has validity info that can be passed from layer to layer. The VFS abstraction is messed up with the concept of "vnode" and "bp", etc. Those don't mean ANYTHING across machines. > > The point in abstraction, however, is not artificial, unless you > only consider one *BSD. If you want to leverage the total *BSD > hacker base to do FS (or any other kind of) work such that it's > applicable to your particular flavor of the month of *BSD, then > you need that type of abstraction. > The abstraction needs to be MESI and VM related. Throw away the old VFS concept -- it was good, but very flawed. You'll never get layering and coherency to work correctly with a VFS only scheme. If you use a VM oriented scheme, your local copy of pages can be copyin'ed or copy'outed or mmaped. If you take a VFS oriented approach, then you have to deal with something that thinks in terms of buffers that have to be somehow mmap'ed... Bzzzt... That is a terrible mess, and why the FreeBSD VM/VFS code temporarily uses buffers, but uses memory OBJECTS as the repository for data. Try putting together a coherent buffer oriented scheme -- you start ending up with LOTS of limitations and complexity due to the additional level of abstraction. Take Heidemann + VM and object oriented approaches, and you'll get something that works super well (and is practical.) Think more in terms of CORBA (even though not quite that) than uniprocessor programming. The local case can be a degenerate case of the object approach, and can short circuit to minimize copying. > > I really think that the main FS work as time goes on will be in > stacking layers, and not in local media FS's. > Again, I agree, but I am thinking totally in a distributed environment. VFS (as it is today) just doesn't work. If you rename a VM (or object) oriented scheme as VFS, then VFS is okay. VFS as it is allows (and supports) only unidirectional communication... Bzzzt, in a distributed environment. > > Yeah, a local media FS is pretty intimate with the VM system, > especially in the getpages/putpages area (and, if supported as > a direct interface instead of a layer on top of the getpages/putpages, > bmap). But that intimacy should be formally abstract. > But why add additional, and unneeded layers of abstraction, like the way that current VFS works? VFS might be good for naming (but doesn't handle the case of revocation of names correctly, does it?) See, there is just too much hackery necessary when using "VFS" for non-local systems... -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901052205.RAA01732>