Date: Thu, 7 Jan 1999 18:53:36 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Terry Lambert <tlambert@primenet.com> Cc: pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Message-ID: <199901080253.SAA36703@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
:> :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.
<dillon@backplane.com> (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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901080253.SAA36703>