From owner-freebsd-hackers Thu Jan 7 18:54:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA18019 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 18:54:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA18014 for ; Thu, 7 Jan 1999 18:54:07 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id SAA36703; Thu, 7 Jan 1999 18:53:36 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Jan 1999 18:53:36 -0800 (PST) From: Matthew Dillon Message-Id: <199901080253.SAA36703@apollo.backplane.com> To: Terry Lambert Cc: pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :There's *no* memory waste, if you don't instanceincoherent copies :> :of pages in the first place. :> :> You are ignoring the point. I mmap() a file. I mmap() the block device :> underlying the filesystem the file resides on. I start accessing pages. :> Poof... no coherency, plus lots of wasted memory. : :No. You mmap the file. This instances a vnode, and a VM object using :the vnode as a swap store. What do you mean, no? I just gave you an example of something someone might want to do. Now you tell me how to ensure that it's coherent. Disallowing the case is not an option. You can't just ignore cases that don't fall under your model! :Consider the case of an ACL VFS stacking layer stacked on top of :an NFS client and under a system call layer. :... : :For the NFS, the information is directly accessed (with lease :controls -- otherwise known as opportunity locks - for cache :coherency) from the underlying vnode's VM objcts. : :For the ACL FS stacked on the NFS, the VOP_GETPAGES and VOP_PUTPAGES :*ARE PASSED DOWN*. The entire purpose of the ACLFS is to impose :access semantics on the underlying vnode objects. The way it does :this is by a namespace escape of an access control file that it :itself accesses by way direct calls to the underlying NFS. A :(really) hidden file, in other words. : :If we stack a QUOTA FS on top of this, and expose it in another :... :If we stack a RESOURCE FS that turns file creations into directory :... : :In each case, however, the requests to obtain the page for reading :and writing go down to the cnode object off of which it is hung. :... :easy to understand. And in the last case, it doesn't really make :sense to expose the FS hierarchy underlying the RESOURCE FS :layer, because it exposes you to non-cache based namespace coherency :problems (e.g., how do you handle someone CD'ing into a directory That is the whole point of having a cache coherency protocol. Your design is strictly top-down. You are specifically disallowing the case where someone may tap into a node underneath your 'top' node. You are saying, basically, that it is illegal to do so because your mechansism can't deal with the cache coherency problems associated with that sort of access. There's just one problem: I've given you half a dozen cases where someone might want to tap into an intermediate node. :thats a file, and removing the "filedata" file containing the file :data fork, without also removing the associated resource fork or :extended attribute? ... You can't, and the VM cache coherency :protocol you propose won't handle this non-VM coherency problem, :either). Sure it will. You are thinking top-down again. The whole point of the cache coherency protocol is that it is a two-way protocol... it propogates out from the access point and the access point does NOT have to be starting at the top. The vm_object extension ( vm_alias's or something similar ) is simply an optimization, but one that allows the VM system to do its job almost trivially. Now I suppose you could explicitly design the ACL and QUOTA layers to ignore accesses made out from underneath them, but that seems silly to me... I can think of several situations where the QUOTA layer would definitely want to be updated if someone else makes changes to files that it maps without going through it directly. :Part II: The case where cache coherency is a real issue : :So now we build a cryptographic FS. It uses any CDROM as a one :time pad, and does duplicate eliminatation on the CDROM data so :... :The OTPFS (One Time Pad FS) has vnode objects that stack on top :of the underlying vnode objects. : : :Now we have two problems: : :(1) The coherency issue can not be dealt with via aliases : because the data in the decrypted form of a page can : not be used. In other words, there is no direct alias : between one page and the other. They are *procedurally* : related, but not content-identical (we used a OTP to get : around the issue of N:M byte relationships where N != M). If you would go back and fraggin READ the original proposal, you will note that this case is explcitly covered. Terry, READ THE PROPOSAL. You aren't reading it. I have repeated the solution to this case three times so far, I'm not going to do it again. :In other words, we don't need aliases, except in cases where we :introduce unnecessary abstraction and complexity, for the apparent :purpose of requiring aliases. What you've done is taken a bunch of special cases, mostly degenerate ( and all easily covered by our proposed design ) and come to a patently incorrect conclusion about virtually every aspect of our proposed design, trying to debunk it. You then replaced it with an extremely specialized design of your own that covers ONLY those specific cases and nothing else, has all sorts of restrictions, and cannot maintain cache coherency across a network ( you are missing the point big time if you think that the NFS client-server model is what someone would want to use in a network cluster! ). You aren't thinking big enough. You aren't thinking scaleability or extensibility. You aren't thinking networking and clustering. You *definitely* aren't thinking clustering. And you dismissing efficiency as not being significant... well, I can tell you it is *extremely* significant. One of the biggest problems that cache coherency protocols try to solve is to not only make the cache coherent, but to make I/O operations efficient without losing coherency. -Matt : : Terry Lambert : terry@lambert.org :--- :Any opinions in this posting are my own and not those of my present :or previous employers. : Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message