wow, received a *lot* of replies confirming my thoughts about this, and
also providing some more insight into /tmp and swap.
in short,
yes, files in /tmp eat up the available swap if you have /tmp mounted on
swap, as defined in /etc/vfstab
you can also restrict the amount of space available for /tmp by using
the size=x MB option, in the /etc/vfstab file. eg :
swap - /tmp tmpfs - yes size=768m
one more alternative is to mount /tmp as an ufs filesystem on a separate
disk.
also check out the man page on mount_tmpfs
thanks to all who replied.... there are too many to thank everyone
individually, but then thats the beauty of this list!
thanks to those whose replies are still on the way!
regards,
amol
i'm pasting some of the more interesting and thoughtful replies here for
future reference. these are worth a read and worth preserving.
============================================
Actually, it is the other way around, /tmp is mounted on swap. Swap can
be from different places including NFS (diskless), local disk (raw
partition) or a file.
============================================
you don't *have* to mount /tmp in the swap area... the entry in
/etc/vfstab controls how it's mounted.
probably, you should advise users about this. if you have disk space,
you can always use mkfile/swap -a to dynamically increase swap ( and
/tmp ), but yes, tell the users not to do it. You might have to create
writable disk space somewhere else, but you have to protect your machine
from running out of swap.
============================================
The /tmpfs filesystem provides very high performance for temporary
files. It provides the performance by storing the files in memory rather
than on disk. The safest configuration is to NOT use /tmpfs -- I think
this should be the default in Solaris (it is not). However, tempfs can
be very useful if you have a requirement for high speed temporary files
and if all of your applications (and users) are well-behaved (i.e. do
not create large files in /tmp).
The disadvantage of /tmpfs is that the file size is taken directly from
the memory capacity of the machine. A 10Mb file in /tmp will mean that
10Mb less of memory is available to processes. If a large process core
dumps into /tmp, for example, it could easily use all the memory on the
machine. The use of /tmpfs can also be slower if the machine does not
have enough physical memory to run the existing processes (if vmstat
shows paging - do not use /tmpfs).
I have configured my machines with what I consider to be the best of
both worlds by using disk for /tmp and creating a separate /memfs
filesystem for memory files. This allows me to direct the specific
applications that require the high performance files to the /memfs
filesystem without being concerned about some rogue process or user
filling /tmp and using all of the memory on the machine (lots of
processes create /tmp/files).
The following is required to do this:
# mkdir /memfs
# chmod 1777 /memfs
# chown sys:sys /memfs
Add to 'vfstab':
swap - /memfs tmpfs - yes -
============================================
The reason for the existance of /tmp, is to hold transient files. Long
term storage of data in this directory, or /var/tmp, should be strongly
discouraged.
The Sun Operating System, has two "tmp" directories for two reasons.
/var/tmp is intended for files that have a requirement to survive a
system reboot. (ie: editor recovery files) The /tmp directory is
truely temporary, and should not be expected to survive a reboot.
Sun created the 'tmpfs' filesystem to help administrator balance the
need between /tmp and swap space. 'tmpfs' allow the creation of a
filesystem from available swap space. Since a tmpfs doesn't exist until
initiated, it will always come up clean. (Save dramatically, on /tmp
clean up scripts.) Also being a part of the virtual memory space, it
responds to IO requests faster than normal disk based filesystems.
If you are running applications on a system, that is truely a virtual
memory hog, I would suggest moving the /tmp filesystem from swap, to its
own physical disk partition.
============================================
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:50 CDT