Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ames!uhccux!munnari.oz.au!murdu!ucsvc.ucs.unimelb.edu.au!u3364521
From: U3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Virtual Disk (Was Re: Files larger than available memory.)
Message-ID: <1125@ucsvc.ucs.unimelb.edu.au>
Date: 7 Oct 90 05:30:21 GMT
References: <924@ucsvc.ucs.unimelb.edu.au> <1990Sep23.174736.16118@lavaca.uh.edu> <1088@ucsvc.ucs.unimelb.edu.au> <409@tlvx.UUCP> <1124@ucsvc.ucs.unimelb.edu.au>
Organization: I.A.E.S.R., Melbourne University
Lines: 31

G'day,

LC> In article <1124@ucsvc.ucs.unimelb.edu.au>,
LC> U3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) writes: 

LC> {Please forgive the length of this article. I hope you find it worthwhile.}

    [...deleted the gory details...]

LC> A virtual memory fixed disk.

    [...deleted the gory details...]

LC> So what do you think ?  Is this a good level to deal with the solution to
LC> the problem or is it all wet and would s/w VM be a simpler/better/more_
LC> useful way than dealing with the one problem of files that are too large? 

Yes I know. It's all wet. :-(

A program that cannot do VM allocation for a file (even virtual!) larger than
memory is not going to be able to deal with a file from the virtual disk that
is also too large.

Hands up all of you reading this that have posted.. err..um "incorrect ideas"
at 3am in the morning to a newsgroup before.

I suppose a virtual disk is a sort of useful thingie but to me at this moment
it looks like an unnecessarily complicated addbuffers system... :-(

yours truly,
Lou Cavallo.