Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!uvaarpa!murdoch!uvacs!dmw9q
From: dmw9q@uvacs.cs.Virginia.EDU (David M. Warme)
Newsgroups: comp.unix.internals
Subject: Re: RAM disk.
Message-ID: <1990Oct12.190921.28662@murdoch.acc.Virginia.EDU>
Date: 12 Oct 90 19:09:21 GMT
References: <18574@rpp386.cactus.org> <1850@necisa.ho.necisa.oz> <BZS.90Oct9144959@world.std.com> <1990Oct11.185949.29164@iconsys.uucp> <15785@csli.Stanford.EDU>
Sender: news@murdoch.acc.Virginia.EDU
Reply-To: dmw9q@uvacs.cs.Virginia.EDU (David M. Warme)
Organization: University of Virginia Computer Science Department
Lines: 27

In message <15785@csli.Stanford.EDU>, Bill Poser asks:

> Supposing that RAM disk is a wonderful thing, I don't see why it
> requires any change to UNIX. Couldn't the RAM used for this be
> treated as a device and mapped into the filesystem in the same way
> as any other block device? I should think that it would just be a matter
> of writing an appropriate driver.

There are two major reasons this is not usually done:

- It is easier to hook up new gizmo that works through a known
  and tested interface (i.e. SCSI).

- Writing such a device driver would cripple the CPU by forcing
  it to copy data from the RAM partition into the block I/O
  buffer.  Note that disk controllers have DMA which allows the
  data transfer to be done in parallel with other useful CPU
  work, especially if you have a large cache.

If you happen to have a few spare DMA channels on the CPU board
itself, then this might not be a bad idea.  However, vendors
such as Sun, HP, etc are not known for putting spare hardware
into their system that is not already used for something.


Dave Warme,
all disclaimers made, no rights reserved, etc.