>From the feedback I received the best practice is to setup a volume (UFS or
AdvFS fileset) in the /etc/fstab so that it will mount to the /tmp directory
when the system transitions from single-user to multi-user mode.
If you created an AdvFS domain and fileset...
addvol /dev/rz99c tmpdomain
mkfset tmpdomain tmp_files
In /etc/fstab, an entry would then be needed similar to:
tmpdomain#tmp_files /tmp advfs rw
During the transition from single-user mode to multi-user mode the volume would
be mounted.
In our case, using an AdvFS volume will probably increase the speed of our
Oracle upgrades significantly. If speed is critical, one option that was
mentioned was to use a memory file system and map /tmp to it.
Original question:
Jeffrey_Hummel_at_albemarle.com wrote:
>
> For the /tmp directory, which of the following is considered a best practice
for
> it:
>
> 1. Leave it alone.
> 2. Link it so it resides at /var/tmp.
> 3. Link it so it resides on another device (ie. to a spot on an AdvFS volume
or
> some other mountpoint)
> 4. None of the above.
>
> thanks!
> Jeff
>
1. Works unless performance is impacted. One suggestion was to create a memory
file system and mount it using /etc/fstab during the transition.
2 and 3 - links can potentially cause hard to diagnose problems.
Specific excerpts:
===========
Chang Song
This is what I think.
If you have memory to spare and need absolute performance for /tmp, make
it was MFS parition and and put it in /etc/fstab. This is the best approach
when you have enough memory.
If you are tight on memory, but have a disk to spare, newfs the disk
(use UFS) and mount it with "delayed" option. There will be no
synchronous file creation/deletion. This will make all metadata
I/O activity on /tmp very fast. But remember to newfs the disk after
panic or abnormal system shutdown. (fsck will probably not cure all
the problem on the partition that was mounted "delayed".
===========
Larry Clegg
In my book the answer is #1. /tmp under tru64 is not handled like it is
under Solaris. I've been doing Tru64 for a number of years and have never
had any issues with /tmp filling up or causing a performance problem. Our
corporate baseline for Tru64 calls for /tmp to be left alone as it is during
installation.
==========
Tom Linden
Because it has the tendency grow, isolating so it doesn't affect other file
systems is a good idea. I have in the past made 'rm' be a 'mv' to /tmp and
periodically clean out /tmp from
cron. This can save some grief.
==========
Dr. Thomas P. Blinn
/tmp MUST be a directory in the root file system. If it's not, there are
things that will break. Some of them are subtle, and you'll have a hard
time diagnosing what's broken and why.
As the system transitions from single user mode to multi-user mode, it's
OK to mount a different file system on /tmp, but whether you think you'll
be having your system be in a cluster in the future or not, the right way
is to have the "extra space" /tmp be mounted behind a CDSL (as it is in
your current setup).
I recommend you create a "tmp" fileset in your "usr_domain" or if you've
made it separate, your "var_domain" and mount that fileset onto the /tmp
that already exists (add it to your /etc/fstab just like the other listed
AdvFS file systems); that way, it will mount on the existing directory as
the system transitions from single user to multi user mode (when all of
the local file systems are mounted by the bcheckrc script), it will be in
place during your update, and so on. Doing it this way will work, and it
will be transparent to other things, and we won't break it behind your
back later on.
In other words, either leave it alone (make root big enough for your
needs), or mount a file system on it (works flawlessly, even early in
the standalone environment if you use bcheckrc).
The others can and WILL get you into trouble in single user mode.
=========
Douglas L. Thomas
I like to make a separate filesystem for /tmp, usually 100M - 500M, just to
be safe. Of course this depends on Application requirements, too. We're
working on installing Oracle Financials, which requires almost 4G in /tmp (I
will probably shrink it after we go production). Some Application use their
own tmp directory while others use /tmp.
Err on the side of safety, always.
=========
"Alan"
Two more options are:
5. Explicitly mount /tmp as an independent file system
(as opposed to playing games with symbolic links).
6. Use mfs(8) as a variant of the above if you have
spare memory, need a really fast /tmp and don't
mind it being truely temporary.
I don't think much of "link it to something" solutions
because you can't use it running single-user when the
root is the only file system mounted. There may be
interesting applications that need /tmp space then.
By mounting a file system there, the usual root space
can be used until it is mounted.
It probably isn't a lot of extra work to mount the
linked file system if you have to do anything interesting
while running single-user, unless the linked file system
is unavailable. Then you may have a problem if you need
/tmp space.
=========
Alan Davis
It really depends on how the apps running on the system use it. I usually
create a separate filesystem for it and mount it. For v4.x it gets mounted
at /tmp, on v5.x it's mounted at /cluster/members/memberN/tmp. This gives me
the most flexibility.
=========
Steve VanDevender
There is a fairly common assumption that stuff in /tmp can go away after
a reboot, but stuff in /var/tmp probably shouldn't, making #2
potentially problematic.
=========
Kurt Carlson
You ask a simple question, but the answer gets complicated based on
what a system is used for and a site's management practices.
For a general use system, you probably don't want /tmp or any world writable
file system on your /, /usr, or your /var partition containing
system logs|files... you don't want to give users the ability to break your
system or inhibit system logging. For a workstation or limited use
system, it doesn't matter (other than you may want consistent practices
if you manage both).
For clustered systems (Linux or otherwise), you may want to encourage
users to use something besides /tmp. For most brands of Unix /tmp should
be a local (non-NFS) filesystem because some system utilities (and many
vendor scripts) expect to be able to write to it. However, in a clustered
environment users may need a globally available work|tmp space (a /scratch or
a /work vs. /tmp). When nfs mounting, always place the mount-point a
directory beneath /, such as:
/imports/scratch
/scratch -> /imports/scratch
There are at least 2 flavors of Unix which will hang with a simple
stat() (e.g., 'ls -l' or 'find') in a directory with an out of commission
nfs filesystem. This has some nasty implications when the directory
is '/'.
And finally, you might want to consider implementing some form of
auto-purge or quota policy of /tmp. This in itself gets a bit tricky to
avoid problems if you have users who may create files with non-ascii
characters in the filenames (use a safe purge script).
=========
Anthony A. D. Talltree
>1. Leave it alone.
Yes.
>2. Link it so it resides at /var/tmp.
Sooner or later, this will bite you, one way or another, eg. if your
system at boottime clears either /tmp or /var/tmp (I've seen OS's that
do one or the other) but not the other, your users will be upset when
files they wanted to keep disappear.
>3. Link it so it resides on another device (ie. to a spot on an AdvFS volume
>or some other mountpoint)
If you want to make it its own filesystem (isn't it already?) that's
fine, but don't make it a link.
******************************************************************************************
IMPORTANT NOTICE: This email message and any files transmitted with it may be
confidential, may be legally privileged, and are for the intended recipient
only. If obtained in error, please delete this message and confirm the deletion
in an email to the sender.
******************************************************************************************
Received on Tue May 01 2001 - 18:55:48 NZST