[alt.religion.computers] RAM disk.

bzs@world.std.com (Barry Shein) (10/10/90)

>When I hear `ram disk' I reach for my revolver.  Now, repeat after me...

I agree Boyd.

The "problem" Unix is experiencing right now is that it has become
standard in the industry and all these folks from other O/S cultures
are having it thrown in their laps.

Those with some system experience and an opinion immediately begin
shouting for all these jargon items they were sold on from their
former system (systems which, I may add, are now becoming rapidly
obsolete.)

We had a good rash of this when TOPS-20 died a few years ago and lots
of TOPS-20 types who had been switched to Unix suddenly began shouting
for a rework of their favorite features.

Here's several features that keep coming up. Not all are without
merit, but some are already there (like RAM disk) and others are
questionably portable or, well, without merit.

1. RAM Disk

Unix already has most of the advantages of a RAM disk, so this is just
mostly a "jargon" check-off item. Had we called the buffer-cache ram
disk most of these people would not be asking for this today.

2. Caseless file system

This is stupid. The ability to insert and distinguish almost all 256
character codes is used in other languages to great advantage (e.g.
Kanji.)

The point being, a good way to view this is that file names are not
stored in ASCII under unix, they're stored as a string of 8-bit bytes,
so case is only in the eyes of the beholder.

There are a few byte values (such as slash) which are hard to encode,
but so what, you can't give your computer an IP address of all ones or
all zeros either, hardly damning. Out of band values has a long
history in computing and engineering.

3. Asynchronous I/O for "performance" reasons

All Unix block I/O is asynchronous (well, driver dependant of course,
but disks and tapes and so forth.)

The recent addition to Unix has been *synchronous* I/O (FSYNC bit.)
The one major exception is directory updates, but that's never the
issue when this comes up.

Systems like VMS have synchronous I/O as the default so asynch had to
be engineered in as the exception. It's important to understand all
this before shouting for a particular style of programming interface
that probably won't change the performance of your application one bit
(actually, will probably slow it down as now you've added all sorts of
exception handling baggage to a formerly low overhead feature.)

Another related feature is being able to get an interrupt when an I/O
has really gone to disk (et al). This has merit and for many
applications would be vastly superior to the FSYNC bit. I'm not sure
why this hasn't been done universally as the SIGIO signal could just
be used for this and it probably only entails marking a bit in the
buffer and having the kernel issue a psignal() or whatever when the
right completes and the buffer is being freed. Perhaps I'm missing
something.

4. Command names which resemble english words.

Certainly more popular among those who speak english.

Bell Labs commissioned independant studies early in Unix's history to
see if this was important or not. I've tried to locate these, others
have claimed to have been involved and seen the reports. It's possible
they were "internal use only", perhaps the work should be repeated.

The basic conclusion was that you can make commands english, wierd,
mnemonic, and even counter-intuitive (e.g. "delete" means edit a file,
"edit" means delete etc.) and it simply doesn't seem to make all that
much difference to learning curves.

This may seem horribly counter-intuitive and against all conventional
wisdom (some people get quite apoplectic when this is asserted, sort
of like telling them that there is no Santa Claus.)

Consider, for a moment, that the company which produced Unix has had
some moderate success getting the general public to enter long strings
of digits as part of their daily activity. And it is even successful
among children and other idiots, etc.

Motivation to use the thing appears to be more important than what you
call the commands. In the end, the remarkable thing about computers
are the people who use them.

5. TSR's

The MS/DOS community developed these out of utter desparation due to
their single-tasking O/S and the way memory management was
brain-damaged from the start. See "job control". Of no merit.

----------

There are many other things that can go on this list. It might be
interesting to generate such a list and post it monthly along with the
frequently asked questions lists. Something like "Why Doesn't Unix..."
-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD

malc@iconsys.uucp (Malcolm Weir) (10/12/90)

OK, Reach For Your Revolver... Make My Day! But you dudes who say "RAM disks?
Unnecessary, 'cos we've got a Buffer Cache!!" are WRONG, INCORRECT, MISTAKEN,
and basically WAY OUT OF LINE.

Consider the AT&T System Administrator's Guide section on "Performance Tuning".
This source will indicate that it is a Good Thing to put heavily used
directories in the physically-centered cylinders of your faster disks. Obvious,
huh? OK, now stuff the same data on a RAM disk, as a logical extension.
"But", you cry, "the Buffer Cache would do that for us!"

Really? just how do you persuade *nix to cache "/lib/*", in prefence to 
Joe Unimportant-User's huge statistical jobs that have been munging vast
amounts of data for the past 12 days?  How do you persuade it that the
disk accesses caused by the backup of "/irrelevant" are less important than
the accesses caused by the CEO's secretary's WP temp files?

There are MANY applications where RAM disk provide incredible benefits.
Don't disparage them just because you don't know how REAL systems are used,
with varying importance of tasks.

A perfect example of a manufacturer who has done excellent things with RAM
disk is Pyramid Technology. The allow all sorts of neat things to do with
RAM disk, for example:

    * Mirror a RAM disk to a physical disk. The data is *always* in the
      cache, yet will eventually be on magnetic. This does wonderful
      things if you stick database dictionaries/upper-levels on it.

    * Define a logical slice consisting of a RAM disk followed by
      magnetic. The idea being that you get a scratch space that 
      is esp. fast, and has an economic price, but can accomodate
      periodic heavy demands.

Disclaimer: I have nothing to do with Pyramid. In fact, Sanyo/Icon
computers do not support RAM disk, but we do support huge buffer
caches, with a dedicated processor to keep track of whats where.

Of course, RAM disks made from Virtual Memory are truly Stoopid, but
there are even a couple of manufacturers out there who build real RAM
disks: 5 1/4" form factor enclosures, SCSI interface (or whatever), but
huge quantities of DRAM instead of magnetics. The De Luxe versions even
have a battery...  how do these relate to Buffer Cache?

(btw, I used to be anti-RAM-disk, 'till I tried a system with "/lib"
 on RAM. "/tmp" didn't make that much difference, but you should've
 seen "ld" fly... )

Malc.

poser@csli.Stanford.EDU (Bill Poser) (10/12/90)

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.

mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (10/15/90)

In article <1990Oct11.185949.29164@iconsys.uucp>
	malc@iconsys.uucp (Malcolm Weir) writes:

>OK, Reach For Your Revolver... Make My Day! But you dudes who say "RAM disks?
>Unnecessary, 'cos we've got a Buffer Cache!!" are WRONG, INCORRECT, MISTAKEN,
>and basically WAY OUT OF LINE.

Not so much.

>Really? just how do you persuade *nix to cache "/lib/*", in prefence to 
>Joe Unimportant-User's huge statistical jobs that have been munging vast
>amounts of data for the past 12 days?

As /lib is almost readonly, I recommend you to tune BSD file system
parameters such as maxcontig with appropriate disk controllers.

Then, you can read entire /lib/libc.a with a single seek.

>How do you persuade it that the
>disk accesses caused by the backup of "/irrelevant" are less important than
>the accesses caused by the CEO's secretary's WP temp files?

CEO's secretary should have his own workstation, of course.

>(btw, I used to be anti-RAM-disk, 'till I tried a system with "/lib"
> on RAM. "/tmp" didn't make that much difference, but you should've
> seen "ld" fly... )

If you are using your own workstation with large memory and dynamic
buffer caching, you can observe the same thing.

						Masataka Ohta

lm@slovax.Sun.COM (Larry McVoy) (10/17/90)

In article <6372@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>As /lib is almost readonly, I recommend you to tune BSD file system
>parameters such as maxcontig with appropriate disk controllers.
>
>Then, you can read entire /lib/libc.a with a single seek.

Don't try this at home, kids, unless you know what you are doing.  This will
work pretty well for the newer SCSI drives that have track buffers but it will
work horribly for old drives such as SMD's (eagles) and older SCSI.  The 
controllers mentioned are not common on work stations.
---
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm@sun.com