SUMMARY - Regarding DEC Memory File System

From: Emanuel Salazar <Emanuel.Salazar_at_mci.com>
Date: Mon, 18 May 1998 12:07 -0600 (MDT)

I am writing to provide a SUMMARY of the responses to my request for
help, and to thank everyone on the list. My special thanks to the
following people for responding to my request: MC.Vialatte, Steve
Butcher, Paul Henderson, Valentin Nakov, Alan Rollow, Dr. Tom Blinn,
and Brian Hostetter.

Original posting:
-----------------
system: DU 4.0d, Alpha 4100, 6GB Memory, HSZ70 with 40 rz29 disks

I am writing to ask if anyone has experience using DEC's Memory File
System. I am looking for how-to install and configure type of
information, and any pitfalls I should avoid. My literature search has
yielded no helpful information.

My intent is to create a 300 MB ram disk for /var/tmp and place
ObjectStore files there to improve performance. ODI (the Objectstore
people) have suggested this to my user and they want to try it.

SUMMARY
-------
It is really easy to do. Add this to /etc/fstab do a # mount -a
command. The fstab entry should be something like :

-s614400 /DIRECTORY mfs rw 1 0

614400 defines the size of the RAM disk in 512-bytes blocks
/DIRECTORY is /tmp or /var/tmp or ...

Look at the man page for mfs(8). It is part of the newfs(8) man
page. It details how to create a memory file system, and how to mount
it. Please note the following: the contents of a memory file system
are lost whenever a reboot or unmount is performed.

There's nothing to install since it is part of base system's UFS
support. The manual page on modern versions shows how to use the
command to create one interactively and how to create one at startup
through /etc/fstab. There appears to be potential for trouble creating
very large file systems with it, but 300 MB shouldn't be a problem.

You may want to have 2nd thoughts about putting /var/tmp on it
through. While the application may treat it is very temporary space
other applications may not. Some editors probably put their temporary
files there and the crash recovery of those editors depends on the
file system surviving a reboot. If you have other applications that
may expect /var/tmp to survive a reboot, see if they support use of
TMPDIR to specify an alternate temporary directory.

*** alternatively,

Another way to size the mfs is to pick a suitably sized partition on a
disk and use that, like this:

/dev/rz0b /var/tmp mfs rw,-i1024 1 0


This will make an mfs the size of /dev/rz0b and use "-i1024" when
setting up the file system (it does an implicit newfs with the
parameters you provide). Additionally, you MUST have enough swap space
to contain your mfs, since pages in the mfs will get swapped out if
there is not enough system memory for the mfs and everything else on
the system. Make sure your mfs gets mounted after /var (or /usr if
/var/tmp is just in /usr/var/tmp). If there is ANYTHING in /var/tmp
before you mount the mfs, then you MUST be sure to copy it into some
other place BEFORE you mount the mfs, then copy it back.

NOTE: that some things write stuff into /var/tmp that they really
expect to be preserved over a crash -- vi in particular puts editor
buffers there when a user process is forcibly terminated (via hangup),
and if you reboot, then the users' buffers will be lost. This is NOT
good. But if you don't care, then putting the mfs in place of /var/tmp
may be OK.

This begs the question of getting the files into /var/tmp that need to
be put there on reboot. You will need to write a suitable shell script
and make sure it gets run.

=============

Again, my thanks to the list and a special thanks to the persons
responding to my request for help.

emanuel.salazar_at_mci.com
719-535-1292/VNet 622-1292
Received on Mon May 18 1998 - 20:09:38 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:37 NZDT