/xenix: RAMDISK and Other Uses of Memory
©1987 - Richard A. Bilancia - All Rights Reserved
to be published first in the December 1987 issue of UNIX&reg/World

A large number of us are often guilty of trying to compare DOS with !!unix!!, trying to definitively determine which operating system is best. Obviously such a determination is fruitless because each operating system is best for different purposes and different applications. With this in mind, I’d like to discuss this month an often discussed feature of some DOS software, called **ramdisk** software, that has finally made it to !!xenix!!.

First of all what is **ramdisk**? It is software that allows some portion of available memory to be used as if it were part of a disk storage device. It therefore can be thought of as a very fast, but usually somewhat size limited, pseudo-disk drive. The primary reason for **ramdisk** popularity rests with three simple facts: (1) that a large base of application software is not user modifiable; (2) for one reason or another that software is disk (or diskette) I/O bound; and (3) random access memory has decreased considerablely in cost. All of these factors create an environment where such **ramdisk** software can significantly increase the speed of execution of an application or system at a relatively modest cost.

This month I’ll be focusing on the 286 and 386 !!xenix!! **ramdisk** opportunities that are available without any additional software costs (even you don’t own the !!xenix!! software development tools), and two separate software packages available for the Tandy 6000 running Tandy’s version of !!xenix!! 68000.

Now on to the good stuff!

The SCO implementation of **ramdisk**

Like many parts of the !!unix!! system, powerful utilities, concepts and/or features are documented in a few short pages somewhere in the operating system manuals waiting for the creative and innovative to exploit their use. Such is the case with the **ramdisk** feature in SCO !!xenix!! System V/286 and SCO !!xenix!! SystemV/386. Less than three pages describe the use of **ramdisk** in the hardware (HW) pages of the "Run Time Environment" !!xenix!! manual. Without even the need for the !!xenix!! development system, the !!xenix!! runtime allows you to allocate your own **ramdisk** portions of memory in sizes from 16K to 512K in both temporary and permanent configurations.

Rather than repeat a lot of the technical details that can be found in the above mentioned manual pages, let me show you how simple it is to create, configure and use a permanent 512K

**ramdisk**.

First, start out by logging into your system as **root**, and type the following commands to create the **ramdisk** device file and make it writable by all users:

These above commands need to be executed only one time on each system. The following commands, however, will need to executed each time the system is rebooted, and therefore should probably be added to your system **/etc/rc** file so that they will be automatically executed each time the system is restarted:

The first of these two commands creates a file system on the memory allocated for the **ramdisk**, while the second command mounts the **ramdisk** in the **/mnt** directory (assuming that the **/mnt** directory already exists). That’s all there is to it!

From this point on, files can be created in the **/mnt** directory, the same as any other directory, but the files will never be written to disk but rather stored only in RAM. Any command or operating system call that operates on disk files can also be used to operating on **ramdisk** files. You should note that I could have chosen to mount the **ramdisk** in the **/tmp** or **/usr/tmp** directories, but did not to do so because I’d then be limited to storing a maximum of 512K in either directory. In different applications either choice might be the more appropriate.

In conclusion, let me review some of the cautions to be observed when using !!xenix!! **ramdisks**. First, it’s probably best to allocate **ramdisks** when starting up the system. For that reason several of the necessary commands used to create the **ramdisk** can be placed in the system **/etc/rc** startup file. Next, make sure that you have enough memory in the system, otherwise you may even create a system degradation rather than the improvement you’re after. What’s enough memory? That depends upon the load of your system and the applications you’re running. The key here is to minimize any unnecessary swapping of active processes (more on swapping later). In fact the !!xenix!! manual states that, "In many cases, you will notice a decrease in system performance when **ramdisks** are used, because !!xenix!! can generally put the memory to better use elsewhere." So finally, therefore recognizing that **ramdisks** should only be used for very special situations, make sure that you test and benchmark your application before and after the implementation of **ramdisks** to be sure that you’re getting the performance improvement you’re after.

The Tandy 6000 **ramdisk**

While the above procedures for creating and using a **ramdisk** are fine for Intel based !!xenix!! users, Tandy 68000 !!xenix!! users need not despair! Microlite Corporation (Pittsburg, PA) has created a software product that will behave quite similarly on Tandy 6000 systems. The software is available for use with his 2 meg RAM boards for the Tandy 6000 that I described in my August column. As far as I can tell, the Microlite software should also run with Tandy’s (Fort Worth, TX) 1 meg RAM boards (if you have enough free slots) and SnappWare’s (Cincinnati, OH) 1 meg and 2 meg RAM boards.

I’ve recently also learned of another RAM board manufacturer for the Tandy 6000 -- Associated Solutions (Roswell, GA). The boards from Associated Solutions while physically no larger than the others, are available in 3 meg and 4 meg RAM configurations. Associated Solutions recently sent me an evaluation 4 meg board that I have running in my Tandy 6000. The board is cleanly made and has been just as reliable as the other memory boards I’ve used. I’ve had no problems with it whatsoever.

One of the biggest problems that Tandy 6000 owners have experienced is relatively limited space available for additional boards in a Tandy 6000 (to say nothing of us model 16a owners who have 2 fewer slots than a 6000). Now with this larger selection of alternative memory boards, this problem is of much less significance.

Swap space in RAM

One of the other potential uses for additional memory in !!xenix!! systems is to implement the system’s swap space in RAM rather than on the hard disk. While at first glance this seems like an unnecessary hardware overkill, and for systems that can address large amounts of memory it probably is, for certain systems it is a very viable solution for improving system performance.

First, what is the problem we’re trying to solve? In the !!unix!! operating system when the size of all the processes requested to be currently executed exceeds the available RAM, the !!unix!! system kernel temporarily suspends the execution of one or more processes by removing the process instructions and data from memory and placing them in a temporary place on the hard disk called the "swap" space.

Consequently, if more memory is available why implement swap space in RAM rather than simply expand the existing real memory? I can think of only one good reason: the operating system kernel cannot address more than a specific amount of real memory even though the CPU might be able to do so. Such is the case with the

Tandy version of !!xenix!! 68000 -- there is a limit in the kernel of 1 meg RAM for real memory.

SnappWare has a solution to this problem: it’s called MemSwap. In addition to the above mentioned memory boards, SnappWare has developed and markets a product that replaces the swap space on a hard disk with RAM loaded above the 1 meg range of real !!xenix!! 68000 memory in a Tandy 6000. I know several locations that use this software, and the performance improvements that I’ve seen on systems that swap large amount of programs and data is quite remarkable.

While SnappWare’s software currently runs on Tandy !!xenix!! 68000 version 03.01.xx, rumor has it that a similar feature will be included with Tandy’s promised (and long awaited) version 03.02.00 of !!xenix!! 68000. I guess we’ll just have to wait and see.