Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site wanginst.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!think!mit-eddie!genrad!decvax!wanginst!vishniac
From: vishniac@wanginst.UUCP (Ephraim Vishniac)
Newsgroups: net.micro.mac
Subject: Re: New Product Idea: external ram disk
Message-ID: <519@wanginst.UUCP>
Date: Mon, 29-Apr-85 08:20:28 EDT
Article-I.D.: wanginst.519
Posted: Mon Apr 29 08:20:28 1985
Date-Received: Wed, 1-May-85 06:49:11 EDT
References: <1255@eagle.UUCP>
Distribution: net
Organization: Wang Institute, Tyngsboro, Ma.  01879
Lines: 23

In a similar vein (novel sorts of RamDisks), how about a "smart"
ramdisk that does data compression/decompression on the fly?  I'd
take odds that the actual information content of an apparently full
400k floppy could be expressed in less memory at some cost in 
coding/decoding.  Packbits might be the fastest and easiest way to
go (although not necessarily the most space-efficient).  Now your
puny 316k ramdisk can contend with your beefy 400k floppies! :-)

Some problems: What's the size of such a ramdisk?  Depends on what's
in it.  How do you decide what's safe to copy in?  Should you
overcommit?  Undercommit?  What if the disk is full and someone
re-writes a sector with less compressible data?

I see some possibilities for dealing with these problems.  If you're
low on space (more than x% of real memory full), you could snarf a 
little from the heap and declare yourself full, for example.  But,
your ramdisk support code might become large enough to negate any
net advantage.
-- 
Ephraim Vishniac
  [apollo, bbncca, cadmus, decvax, harvard, linus, masscomp]!wanginst!vishniac
  vishniac%Wang-Inst@Csnet-Relay