Specifically for /tmp:
- Should ln -s /var/tmp /tmp?
In the case of a complete in-memory disk image (think "live boot CD") this might be acceptable, as every byte of RAM needs to be squeezed. Otherwise, unless you are hard-pressed for disk space, no. /var has its own peculiarities and mixing /tmp with /var/tmp may have unintended consequences when performing systems maintenance. It also adds an extra dependency in that /tmp must be mounted for /var/tmp to function properly; not everything needs /tmp and you may have a situation where you want to migrate it to a different partition or drive, but can't, because you don't want to unmount /var.
- Should /tmp be preserved between reboots or not?
No. If you are relying on this as a consistent behavior then you will, sooner or later, encounter issues.
- Should /tmp be on a real disk area or allowed to be implemented basically on the SWAP area (or tmpfs)?
When it's heavily used, this is a temptation - "we'll put /tmp into a RAM disk, it'll speed up access, and when the system reboots/shuts down, there's nothing to clean up". However, if you are thinking of implementing temp space as a RAM disk that will be swapped, then I would consider the ramifications of your system's swap space usage by other programs. If swap is there as a form of "emergency overflow" for when the system is in dire straights and needs it, the last thing you need is to have swap space consumed by a runaway process filling /tmp, consuming memory, causing pressure on the VM subsystem to swap to disk. Between swap activity, and the additional I/O streaming into the RAM disk (which in turn may cause additional page-ins to satisfy a seek() ) your system will quickly become I/O bound.
- Should /tmp be on a different disk from the / (root) disk?
Preferably, yes, although it's not necessary. If you make heavy use of it, or have a constant workload that requires it, then definitely yes. Hypothetical example: a database that dumps temp files to /tmp would gain a slight speedup by introducing /tmp to a separate spindle (ie. drive).
- Would you place /tmp on a different disk controller from the / (root) disk?
If you have a requirements for recoverability or speed, then it should be considered.
- Any rules of thumb for the size of /tmp?
It should accomodate 2x your expected workload. By this, I mean that if you have local users regularly using this space, sooner or later someone will do something silly and attempt to fill it up. Having a slight overage will allow you to avoid strange "issues" with programs that stop because their temp files have filled up what space is left.
If this is a "common services" installation, where the server provides one or more network services, but does not host users, then this will probably be on the low side. If this is a multi-user installation, this will be on the high side (yes, there are still places that host actual users and not just their network services).
- How would you manage /tmp space while the system is up? Delete all files > certain age? Leave area alone until it reaches a %age of max?
Look into the tmpwatch command, I think you'll find it suits this part of your question(s) nicely. The command simply deletes any files past a certain age in hours. Depending on how fast it fills up, you could do 30 days, 45 days, 90 days, etc.
- Should any procedural items be placed into effect to govern this area?
I would recommend the following:
- All files are transitory, and are not guaranteed to survive a reboot.
- Stale files past %age will be removed nightly at midnight local time via a cron job that runs the tmpwatch command.
The rest is a matter of your specific needs.
