|
UNIX Hints & Hacks |
 |
||||||||||||||||||||||||||||||||||||
|
Chapter 6: File Management |
|
||||||||||||||||||||||||||||||||||||
|
Knowing where to put temporary files can be key to saving or losing the files. There are four types of temporary areas that should be used when managing files and the system.
Flavors: AT&T, BSD
When a file is put in /tmp it can be expected that it will be removed either at a scheduled time or the next time the system reboots. This area is designated for what it truly is, a place for temporary files. The system checks and uses the /tmp area for its own use as well. Some flavors, such as Solaris, actually have /tmp be the swap partition. As you know, nothing ever lasts very long in swap. Do not store anything long-term or even something that you might need in a couple of hours. It might not be there when you return.
Many times system administrators put patches, restored data, log files, and other useful files into /tmp. This is considered taking an unnecessary risk. So what does get stored in /tmp?
This area is extremely useful for creating data files for testing, lock files, and other files that you expect to be removed if forgotten about. Do not put any vital data or programs into /tmp. On some flavors, at the time of booting the system, a recursive deletion of files doesn't take place. You can create subdirectories with files in them and not worry about the files being removed. Check with your flavor of UNIX--if /tmp makes up the swap partition on your system, you will not be able to get away with this hack.
Large temporary files should not be kept in this area. The /tmp directory often resides in the root partition. If the root partition fills up, this can lead to the system crashing or grinding to a halt. If you have the disk space you should leave it on the root system.
If the /tmp area is inaccessible, the system does not boot up into a multiuser state. Avoid doing certain things with /tmp to save yourself a lot of grief in the long run:
Never have /tmp as a symbolic link to another partition, if the partition is corrupted and fsck is unsuccessful, the system will not come up.
Never create a link to another temporary area, like /var/tmp. If the partition to the directory doesn't exist or the system is unable to mount the filesystem, the system will be unable to boot up.
Never put /tmp on a second disk. If the second disk loses power, gets corrupted, or fails, the system will not boot.
Flavors: AT&T, BSD
In many cases you will see that /usr/tmp is a symbolic link to /var/tmp. Files that are kept in /usr typically are not supposed to fluctuate in size. Those areas in /usr that do change in size are often linked to /var or some other area with more disk space than /usr. These directories include mail, local, spool, and even tmp.
The size of this temporary area is often larger then the /tmp area. It is an area that is good for storing application-related temporary files, patches waiting to be installed, and administrative temporary files, such as log files, build reports, or anything that doesn't need permanent storage. Files here have to be removed manually from a scheduled job that is set up from the crontab.
If /var/tmp lacks sufficient disk space to handle the temporary area and the disk fills up, the only things that would break are any services in /var. These could include mail, printing, scheduling, and accounting. Although it is not recommended or good administrative practice, if there is more disk space in /usr then in /var, you can reverse the direction of the symbolic link.
Where:
rocket 25% ls -l /usr/tmp lrwxrwxrwx 1 root sys 8 Nov 21 00:07 tmp -> /var/tmp
Becomes:
rocket 26% ls -l /var/tmp lrwxrwxrwx 1 root sys 8 Nov 21 00:07 tmp -> /usr/tmp
Most users and developers do one of two things. They are unaware that this area exists and come close to filling up /tmp. Then there is the other end of the spectrum: They exploit the area to the fullest and you have to sometimes fight to get the area cleaned up.
Flavors: AT&T, BSD
Now that there is an increase of available disk capacity on a single disk, multiple disks and raid arrays are becoming more prevalent than ever before. It is a good idea to create at least one temporary area on any one of the un-system-related filesystems. If you have multiple volumes or filesystems like /vol01, /vol02, and /vol03, select one that might not fill up as fast as the others and make a temporary directory within it (that is, /vol02/tmp).
This new area can be designated just for the users. This temporary area is perfect for the users to use or throw whatever files, extraneous code, and data that they want to temporarily work with. Make it known to the users that this area is set up just for them. They need to be informed that they can work in this area and stay out of /tmp or /usr/tmp, they will not be affecting the system disks in any way, and they might also show an increase in performance if they stay in the designated temporary area you set up for them. Users always like to hear about anything that might show an increase in performance to their system.
In many cases you don't know what the user is up to or what programs they are running or trying to run. Unlike /tmp and /usr/tmp, which can have files removed on a regular basis, the removal of data here can be handled in two ways. If the disk utilization meets a certain threshold, like 95%, files older that 3-7 days can be removed. You can also set up the crontab to remove data older than n days on a weekly basis. Check with the main user or project leader of the system to find out which method they would prefer.
If this area can be viewed by many workstations over NFS mount points, you might want to put files that are of interest to many users in this area. Many times large files on the Internet can be of interest to users. These sometimes can be files or programs that more than one user will want to see but not keep. Sometimes many users want to view large and popular QuickTime movie files. It is best to take a proactive approach and place these files into the temporary area so that you don't have so many copies of a large redundant file sitting all around your system. You can do the math of a 30MB file with 100 users each wanting a copy. Think of all the wasted tape you will be using for backups and disk space. Check with management first.
In many cases, downloading these types of files is prohibited by company policy. Management has been known to be lenient depending on the environment and the content of the material. Typically it is nonpornographic material and isn't in poor taste. It can also be justified by explaining the amount of disk space, tapes, and time that potentially could be wasted by their employees. If any disks have filled up in the past due to a similar instance, you should notify management that this could be a way of preventing this sort of thing from happening again.
Flavors: AT&T, BSD
Setting up a temporary area in a user's home directory works very well to keep the user out of the system's temporary directories. Users can place any downloaded files or data they are temporarily working with in this area. Eventually disk space fills up; when it does and the call goes out to clean up files, users can go straight to their temporary area and clean up these files first.
This is sometimes a cleaner alternative to one large temporary area on an extra filesystem for many to share. If a large number of people are accessing the one shared area, some begin to look elsewhere for other places to start dumping files.
There is never a user who keeps things forever; everyone needs a place to occasionally dump their junk files. A directory for temporary storage is necessary for the user and its location can be vital to the integrity of the system.
Users often need to be told where to put files, and you need to be the one to tell them. If you configure the system, you should know what's best. When users do not have any place to store things temporarily, they have a tendency to begin creating frivolous and meaningless directories throughout the system. Administering and cleaning up these directories and files become a nightmare.
Backups should never be done on any temporary directories or files unless specifically requested by a user. If it is requested, try to make it clear that these backups will take place for only n days and then will cease to exist. In a year's time, performing backups on these areas could run to gigabytes of worthless space and data.
When you are working with temporary directories, keep in mind some of the basic rules that should be covered.
/tmp should always remain on the system drive and never be linked to a filesystem that is not part of the system drive.
/usr/tmp and any symbolic links for it, should always remain on the system drive. It can have a symbolic link to other filesystems not on the local system drive, but at a risk to the systems services.
/tmp and /usr/tmp should never be NFS mounted.
/tmp should never be linked to /usr/tmp and /usr/tmp should never be linked to /tmp.
Temporary directories in multiple un-system-related filesystems can be linked to another drive local to the system or even across an NFS-mounted filesystem with little-to-no risk to the system.
/usr/tmp should not be linked to an extra shared temporary directory on another filesystem.
|
UNIX Hints & Hacks |
|
||||||||||||||||||||||||||||||||||||
|
Chapter 6: File Management |
|
||||||||||||||||||||||||||||||||||||
|
© Copyright Macmillan USA. All rights reserved.
