fast mapcalc

[Gerald I. Evenden]

>Date: Tue, 4 Jul 95 12:05:36 EDT
>From: tmoore at pnfi.forestry.ca (Tom Moore)
>To: grassu-list at max.cecer.army.mil
>Subject: Re: fast mapcalc
>
>In mailgate.grass.user you write:
>
>>OK smart fellas, show me!  Name four major commercial Unix systems with
>>"ram-disk" and specifics about mounting procedures.
>
>>I can verify on Sun OS, a couple of DEC flavors, SVR4.  Reference to
>>"man" pages acceptable.
>
>I don't know about anything other than SunOS and Linux, but there
>are memory based file systems for both of these OS.  Linux
>has already been mentioned.   For SunOS 4.1.3 see the man page
>for tmpfs.

OK, I'll look under said subject.  But since the only Sun locally
does not have online man, I'll have to defer such a check until a
site visit.

But man's for SVR4 do not contain anything that I can find.
Ditto for DECs.

>Virtual memory file systems have been around for a long, long
>time.  In my IBM s/370 MVS days there was a JCL parameter
>for "disk=vio" which would allocate space for the file in virtual
>memory.  This was over 15 years ago.

Let's not mention "virtual memory" in the same breath with file
systems.  Two entirely different subjects.  Secondly, I have no doubt
that archaic OS's have memory file systems---Unix is the only issue
here.  Another good example is DOS.

>Under Linux and SunOS 4.1.3 the memory based file systems behave
>just like disk based file systems.  The same concept of access
>permissions and file sharing applies.  All of the usual disk management
>commands (ls, cp, mkdir, rm, chmod, chown ....) work as normal.

Would be expected.

>As was mentioned in an earlier post, root access is required to
>create and attach file systems (unless you are running an unusually
>lax system).  You also need to have the file system drivers loaded
>into the kernel.  

Also expected for such a manipulation.

>Tom

Even if this mechanism is available (spottily) I cannot see any
practical reason for it.  We're not working on floppies any more.
If the file is of any size, the necessary size of the ram area
would cut into the operational area and creat an overhead of swapping.
Is anything bought with this idea?  Secondly, the OS could catch the
fact that a recently "written" file is still in RAM, by virtue of the
buffering, and thus read it out of the buffers rather than going
to the hard drive.  A lot of memory is already taken up with the
buffers.

I could see a possible application for *very* small, *very* frequently
used files, but I doubt that there is much practical return.  On older
Unix systems, I have noted that reexecuting a program accessing a file
that execution was much faster on immediate reexec, presumable because
the OS new the material was still avail in the buffers as well as the
program.

Secondly, the original problem that started the bruhaha was much more
effectively serviced by shared memory rather than fussing with archane
and questionably available ram-disk.  BUT, I dare say that implementing
anything like this in a transportable manner is, to say the least,
difficult.

Gerald (Jerry) I. Evenden   Internet: gie at charon.er.usgs.gov
voice: (508)563-6766          Postal: P.O. Box 1027
  fax: (508)457-2310                  N.Falmouth, MA 02556-1027