How to convert /tmp to memfs after install
Steve M. Fabac, Jr.
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?
--
Steve Fabac
S.M. Fabac & Associates
816/765-1670
Bob Bailin
"Steve M. Fabac, Jr." <smf...@att.net> wrote in message news:4353316A...@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!)
Bob
Bela Lubkin
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<
th...@whasup.com
Regarding the "mount" command, try:
/etc/fscmd.d/memfs/mount memfs MOUNT_POINT
-3-
Jean-Pierre Radley
| 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.
...
| 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...)
As shipped, vi on OSR 6.0.0 still uses /tmp, so here I've included
'dir=/usr/tmp' in my EXINIT, given that my /tmp is an memfs filesystem
but my /usr/tmp is not.
--
JP
Bela Lubkin
That works for you, but it's difficult to implement for all users since
`vi` doesn't have a system-wide exrc file. You could create one in each
user's home directory (add it to the /usr/lib/mkuser/... scripts), but
that's clumsy.
Plus, there may be more obscure dependencies that you haven't noticed,
but are still harming you in some manner.
>Bela<
Steve M. Fabac, Jr.
Wow, that sort-a-works:
# /etc/fscmd.d/memfs/mount memfs /tmp
# df
/ (/dev/root ): 2786668 blocks 179698 i-nodes
/stand (/dev/boot ): 63478 blocks 10218 i-nodes
/proc (/proc ): 0 blocks 9839 i-nodes
/dev/fd (/dev/fd ): 0 blocks 0 i-nodes
/dev/_tcp (/dev/_tcp ): 0 blocks 0 i-nodes
/u (/dev/u ): 11872616 blocks 765972 i-nodes
/app1 (/dev/app1 ): 15650076 blocks 1009671 i-nodes
/system/processor (/processorfs ): 0 blocks 0 i-nodes
> /tmp (memfs ): 3607960 blocks 32766 i-nodes
# dfspace
/ : Disk space: 1360.67 MB of 3000.99 MB available (45.34%).
/stand : Disk space: 30.99 MB of 39.99 MB available (77.49%).
/u : Disk space: 5797.17 MB of 6000.99 MB available (96.60%).
/app1 : Disk space: 7641.63 MB of 8137.82 MB available (93.90%).
>/tmp : Disk space: 1760.45 MB of 1997.94 MB available (88.11%).
Looks like it grabbed all available memory to create almost 2G memfs
But since the system only has 1G of RAM, the above result is suspicious.
Ok, that's more information (/etc/fscmd.d/memfs/mount memfs MOUNT_POINT)
than I was able to dig from the SCO DOC's but does not duplicate the
/tmp memfs created upon install if the option is checked during ISL.
>
> -3-
Steve M. Fabac, Jr.
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!
th...@whasup.com
Try this one:
mount -F memfs -o swapmax=SIZE_IN_BYTES /dev/mem MOUNT_POINT
-3-
Bob Bailin
<th...@whasup.com> wrote in message news:dj2ob6$evg$1...@reader2.panix.com...
[...]
> Try this one:
>
> mount -F memfs -o swapmax=SIZE_IN_BYTES /dev/mem MOUNT_POINT
"/dev/mem": a crucial bit of info left out of the man page.
After first mistyping the 'swapmax' option as 'swapmem', I see that
/etc/mount is a script that calls the appropriate mount binary, in this case
for memfs it's 'mount.svr5':
# mount -F memfs -o swapmem=64000 /dev/mem /tmp
UX:memfs mount.svr5: ERROR: illegal option: swapmem=64000
UX:memfs mount.svr5: TO FIX: Usage:
mount.svr5 [-F memfs] [generic_options] [-r] [-o {swapmax=xx | global_swapmax=xx
}, rootmode=xx] special mount_point
Does 'special' have to be /dev/mem, or is this parameter ignored?
According to this test:
# mount -F memfs -o swapmax=64000 /dev/tty /tmp
# df -v
Mount Dir Filesystem blocks used free %used
/ /dev/root 5426356 3993352 1433004 74%
/stand /dev/boot 81918 12806 69112 16%
/proc /proc 0 0 0 -
/dev/fd /dev/fd 0 0 0 -
/dev/_tcp /dev/_tcp 0 0 0 -
/system/pr /processorfs 0 0 0 -
/tmp /dev/tty 128 0 128 0%
it seems to be ignored. Therefore, the /etc/mount script should be
modified to supply a dummy '/dev/mem' argument when -F is memfs,
if only to avoid bogus filesystem entries in df -v listings.
Bob
Jean-Pierre Radley
| 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.
That's one solution; another is to edit line 85 of /usr/lib/cleantmp:
s/atime/mtime/
--
JP
Bela Lubkin
Jean-Pierre Radley wrote:
It's that way for a reason. There are many utilities that create files
in /tmp and continue to use them for their entire runtime, but don't
modify them very often. If `cleantmp` operates on mtime, those
utilities lose.
>Bela<
Steve M. Fabac, Jr.
With the above items as examples, I added the following to /etc/default/filesys:
bdev=/dev/mem mountdir=/tmp mount=yes fstyp=memfs \
rcmount=yes fsck=no rcfsck=no mntopts=global_swapmax=120000000
bdev=/dev/mem mountdir=/var/tmp mount=yes fstyp=memfs \
rcmount=yes fsck=no rcfsck=no mntopts=
And after rebooting I see:
# dfspace
/ : Disk space: 1344.51 MB of 3000.99 MB available (44.80%).
/stand : Disk space: 30.99 MB of 39.99 MB available (77.49%).
/u : Disk space: 5797.17 MB of 6000.99 MB available (96.60%).
/app1 : Disk space: 7641.63 MB of 8137.82 MB available (93.90%).
/tmp : Disk space: 114.43 MB of 114.44 MB available (100.00%).
/var/tmp : Disk space: 114.43 MB of 114.44 MB available (100.00%).
Total Disk Space: 15043.19 MB of 17408.70 MB available (86.41%).
# df -i
Mount Dir Filesystem iused ifree itotal %iused
/ /dev/root 180123 177565 357688 51%
/stand /dev/boot 22 10218 10240 1%
/proc /proc 71 9830 9901 1%
/dev/fd /dev/fd 9 0 9 100%
/dev/_tcp /dev/_tcp 0 0 0 -
/u /dev/u 4 765972 765976 1%
/app1 /dev/app1 89 1009671 1009760 1%
/system/pr /processorfs 3 0 3 100%
/tmp /dev/mem 4 32764 32768 1%
/var/tmp /dev/mem 2 32766 32768 1%
So, 120M memfs for /tmp is probably excessive but, Hey, I got 1G
total RAM on a test system. The next time I have to install a
6.0 Enterprise system, I will record the settings from
/etc/default/filesys after enabling /tmp memfs in the ISL
configuration screen.