Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site wateng.UUCP Path: utzoo!watmath!wateng!pdbain From: pdbain@wateng.UUCP (Peter Bain) Newsgroups: net.arch Subject: Re: Magic Cookies and File Systems (Religious FLAME) Message-ID: <2123@wateng.UUCP> Date: Sat, 9-Mar-85 14:17:47 EST Article-I.D.: wateng.2123 Posted: Sat Mar 9 14:17:47 1985 Date-Received: Sun, 10-Mar-85 06:03:35 EST References: <917@sjuvax.UUCP> <538@rlgvax.UUCP> <190@u1100s.UUCP> <1078@watdcsu.UUCP> <5185@utzoo.UUCP> <1091@watdcsu.UUCP> Reply-To: pdbain@wateng.UUCP (Peter Bain) Organization: U of Waterloo, Ontario Lines: 23 Summary: > >point taken, gentlemen. i alluded to this possibility when i spoke >about keeping the file system in real memory. why not map to virtual >memory instead? in fact, why not have an entire file system in virtual >memory? (here i use file system to mean the unix definition of file >system which corresponds to a logical disk pack rather than the ENTIRE >file system.) Sorry, Herb - it's been tried. The system is Multics, (which was designed by MIT, Bell Labs, and GE) and had absolutely everything anyone had ever though about putting in an operating system. :-) ) The problem with files == segments in Multics was that everything was demand paged, and so if you were going through the file sequentially, your working set got cluttered with stale pages. I am not saying that this has to happen, but that it's not quite as simple as it appears. -- - peter bain ...!{allegra|decvax|clyde|ihnp4 }!watmath!wateng!pdbain hard mail: CCNG, CPH-2369A, University of Waterloo, Waterloo, Ont. Canada N2M 5G4 telephone: (519) 885-1211 x2810