Date: Tue, 6 Jan 1998 00:12:15 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "John S. Dyson" <toor@dyson.iquest.net> Cc: dyson@freebsd.org, cvs-committers@freebsd.org, cvs-all@freebsd.org, cvs-sys@freebsd.org Subject: Re: John's latest VM commit. Message-ID: <Pine.BSF.3.95.980105235915.7998F-100000@current1.whistle.com> In-Reply-To: <199801060756.CAA05511@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.. > > > > > In his estimation, they contained many of the same fiedls which simply > > meant duplication of information, an danother place where things could get > > out of sync. Of course this was 5 years ago so you may already have > > removed much of the duplication. > > > The vnode and VM object are actually two different things. VM objects are > items of memory. The vnode represents the filesystem's view of one type > of VM object. Note that vnodes have lists of buffers associated with them, > and VM objects have pages associated with them. Buffers are (should be) > there for I/O and temporary mappings (when needed.) Pages associated with > objects are for caching. In my understanding of it, a VM object maps a set of memory resources to some logical set of data. In core pages are just CACHES of the data, wherever it really resides. VNodes on the other hand represent the logical data set, and define the methods used to access that data. These two structures appear to me to be two ways of looking at the same relationship. > > Actually, I would like to see us do away with buffers, except as an > I/O abstraction. The vnodes are specific to a type of secondary storage > object, but do not represent a memory object. NOW you're talking.. But Poul and I have been talking of doing away with buffers AS an IO abstraction. It all flows out of the disk layering. I use bufs at the moment because I'm scared to do otherwise due to the VM ramifications.. I personally think that the way to do it is to have an IO request structure (poul's idea) that references an arbitrary list of PHYSICAL scatter-gather entries(my idea). The IOrequest structure can be cheaply duplicated for use with such things as RAID or mirror handlers. The physical segments needn't be mapped into any address space unless a driver requires that to do programmed IO. > > It would probably be a good thing to make all caching in our system VM object > based. Then buffers will degrade into a structure used to communicate with > I/O devices. I would not like to see the terrible mess that SVR4 has, with > various types of vnode like structures in order to represent swap, filesystem, > device files. 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. :) > > Eventually, as we can deprecate the use of buffer's as a metadata cache, I > think that our buffers will be able to be abstracted as I/O requests, as > they should be. Then, the more general VM objects will be the primary (only) > caching mechanism. so where does the metadata live? > > -- > 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?Pine.BSF.3.95.980105235915.7998F-100000>