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