On Wed, Aug 18, 1999 at 08:43:14PM +0000, Terry Lambert wrote:
> > > > Nope. The problem is that while stacking (null, umap, and overlay fs's)
> > > > work, we don't have the coherency issues worked out so that upper layers
> > > > can cache data. i.e. so that the lower fs knows it has to ask the uper
> > > > layers to give pages back. :-) But multiple ls -lR's work fine. :-)
> > >
> > > With UVM in NetBSD, this is (supposedly) not an issue.
> >
> > UBC. UVM is a new memory manager. UBC unifies the buffer cache with the VM
> > system.
>
> I was under the impression that th "U" in "UVM" was for "Unified".
>
> Does NetBSD not have a unified VM and buffer cache? is th "U" in
> "UVM" referring not to buffer cache unification, but to platform
> unification?
>
> It was my understanding from John Dyson, who had to work on NetBSD
> for NCI, that the new NetBSD stuff actually unified the VM and the
> buffer cache.
>
> If this isn't the case, then, yes, you will need to lock all the way
> up and down, and eat the copy overhead for the concurrency for the
> intermediate vnodes. 8-(.
netbsd w/UVM currently doesn't have unified caches. that feature is
what I named UBC, for "unified buffer cache" (ala DEC's UBC).
the U in UVM doesn't actually stand for anything. :-)
> > > You could actually think of it this way, as well: only FS's that
> > > contain vnodes that provide backing should implement VOP_GETPAGES
> > > and VOP_PUTPAGES, and all I/O should be done through paging.
> >
> > Right. That's part of UBC. :-)
>
> Yep. Again, if NetBSD doesn't have this, it's really important
> that it obtain it. 8-(.
I'm workin' on it... it'll go in soon after the branch for the next release
is created (ie. it won't be in the next release, but the one after that).
-Chuck
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
