Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Jan 1998 03:55:52 -0500 (EST)
From:      "John S. Dyson" <toor@dyson.iquest.net>
To:        julian@whistle.com (Julian Elischer)
Cc:        toor@dyson.iquest.net, dyson@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-sys@FreeBSD.ORG
Subject:   Re: John's latest VM commit.
Message-ID:  <199801060855.DAA07026@dyson.iquest.net>
In-Reply-To: <Pine.BSF.3.95.980105235915.7998F-100000@current1.whistle.com> from Julian Elischer at "Jan 6, 98 00:12:15 am"

next in thread | previous in thread | raw e-mail | index | archive | help
I think that I only replied to you personally, so I'll give a synopsis
of my response to you publically.

Julian Elischer said:
> 
> On Tue, 6 Jan 1998, John S. Dyson wrote:
> 
> > Julian Elischer said:
> > >
> > > Kirk told me a few years ago that he was seriously considering merging the
> > > vm-object and vnode strucures so that one BECAME the other. Is this a
> > > stupid idea? 
> > >
> > I don't think that it is a stupid idea.
> glad to hear it..
>
But I don't think that it is needed either.

> 
> VNodes on the other hand represent the logical data set, and define the
> methods used to access that data. 
>
No.  They represent the filesystem view.

> 
> These two structures appear to me to be two ways of looking at the same
> relationship. 
> 
VM objects might be filesystem backed (VNODE), swap backed(SWAP) or not
backed at all.  A vnode most likely needs an object, but an object doesn't
need a vnode.  It would be wasteful to allocate a vnode for every object.

>
> But every VM object needs an associated VNODE that represents the methods
> and data needed to access teh real backing store.
> and 98% of vnodes are used for file IO (or directory.. same thing)
> so tying the m together may not lose much but may gain simplicity. :)
> 
No.  Not every VM object needs a VNODE.  Not all VM objects need the
overhead of being in the filesystem namespace.  We have the option of
anonymous backing, with a very efficient I/O method, that is not filesystem
or VNODE based.  We also have the option of having objects that are not
backed at all.  All three of these methods are used to advantage in the
current scheme.

Our association between objects and vnodes is much simpler now, and merging
the two will likely increase the total size of the data structures.  There
isn't that much shared between the two (vnodes and objects.)

-- 
John                  | Never try to teach a pig to sing,
dyson@freebsd.org     | it just makes you look stupid,
jdyson@nc.com         | and it irritates the pig.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801060855.DAA07026>