Re: How to convert /tmp to memfs after install

From: Steve M. Fabac, Jr. (smfabac_at_att.net)
Date: 10/18/05 

Date: Tue, 18 Oct 2005 05:24:56 GMT

Bela Lubkin wrote:
>
> Bob Bailin wrote:
>
> > "Steve M. Fabac, Jr." <smfabac@att.net> wrote in message news:4353316A.84F6D02@att.net...
> > >I am installing Openserver 6.0 for the first time on my test system
> > > and blew through the file system configuration during installation
> > > so that /tmp is on the root file system.
> > >
> > > I have searched the documentation without finding a solution on
> > > how to set up /etc/vfstab to create and mount /tmp as memfs
> > >
> > > How do I do that without resorting to a re-installation?
> >
> > Agreed.
> >
> > man mount_memfs
> > is not much help. It implies that you should be able to issue:
> >
> > mount -F memfs /tmp
> >
> > in order to create a memory filesystem that replaces the
> > contents of /tmp, using the maximum value from the memory
> > pool, but all you get is:
> >
> > UX:mount: ERROR: cannot determine special device
> >
> > (no special device is required, because it's a memfs!)
>
> Just be sure you know what you're getting into. Early builds of OSR6
> used the UnixWare startup scripts that would set /tmp up as a memfs.
> Due to observed problems, this was deliberately changed back to having
> /tmp be a regular directory, implicitly on the root filesystem.
>
> Existing OSR5 software had two main classes of clash with a memfs /tmp:
> some scripts expected files to persist in /tmp across a reboot; and some
> scripts expected to be able to make hard links between files in their
> private directories and /tmp.
>
> I don't know of any examples of either of these problems inside the OSR6
> system itself (but there could be some). The main dangers would be with
> your own private scripts and with third party applications, both at
> install and runtime.
>
> Ah, one issue that I do remember: OSR5's `vi` uses /tmp as the default
> directory for edit buffer files. After a crash (panic, power failure,
> whatever), `vi` can recover interrupted edit sessions by reading those
> edit buffers. This will not work if the directory is stored on a memfs.
> But I don't remember whether OSR6 `vi` was changed to avoid this problem
> by using a less volatile temporary directory. (Before you test this for
> yourself, make sure you aren't already overriding vi's temp dir with an
> environment variable or with vi's "set dir=/somewhere/else" directive...)
>
> >Bela<

Bela,

All good points. The first install on OS6 I performed was the 6.0
Starter Edition just to see how it went. I then blew that away and
installed 6.0 Enterprise.

On the Starter Edition install, I checked the options to create
/tmp and /var/tmp as memfs and that worked as expected. On the
subsequent installation of 6.0 Enterprise, (2:00 am) I failed to
see the option to turn on /tmp as memfs (in fact, it may not be
there as that was the only time I have installed 6.0 Enterprise
and I might not have missed it if it is not there.) So, again,
I am trying to recover without resorting to a re-installation
(you know, the way we have to do WINDOWS).

The point on vi is valid, but I don't have a single client that
uses vi except when I am guiding them over the phone to resolve
some issue. So that's a non issue.

People leaving things in /tmp should not expect them to remain
there as /usr/lib/cleantmp is scanning /tmp weekly to remove
old files. Except-- on systems with Backup Edge installed:
Backup Edge with default simple_job is resetting the access
time of all the files on a system every time it performs a
scheduled backup. Therefore cleantemp never removes files
from /tmp and /usr/tmp.

I had to enable advance scheduling in Backup Edge and edit
the "domain" specification to change "preserve atime [N]"
to "Y" and change Diff/Incremental level from "2" to "1"
to stop Backup Edge from resetting the access time on each backup.

As I am still evaluating 6.0, I want to check its performance with
the memfs on my client's applications. I'd like the knowledge to
correct the missed option during ISL without having to re-install.

Just one last observation: If you want to see an SCO FoxBASE
application fly, place it on a ramdisk! Even clumsy programming
(seek record) runs an order of magnitude faster! 

--
                                      Steve Fabac
                                       S.M. Fabac & Associates
                                        816/765-1670