|
|
The philosophy that lead to the arrangement of the current CSEE filesystem is simple: your home directory space is for personal stuff and your center's project space is for shared files:
/home/users/<you> /home/projects/<your center> Your e-mail archives
Your public_html directory
Your thesis
Your "dot files"
Other personal filesResearch data
Papers or other collaborative data
Grant proposals
Any data that will survive you when you graduate or leave CSEE
In short, your home directory should contain things that are considered private and could be deleted when you leave CSEE without detrimental effects to ongoing research. Your center's projects space should be where you store any data that should be left behind when you leave.
For faculty, staff, and center-affiliated full-time Masters or PhD students, this means you can set up a directory (or use an existing one) in /home/projects/<yourcenter>/ as a repository for your research.
Inside each center's /home/projects/ space there are no per-user quotas. Instead, these areas are NetApp "quota trees": areas which have an overall fixed limit but which give center members the ability to manage for themselves the layout and space consumption inside the tree.
(Note: Currently, there are no end-user tools for checking on the capacity of each center's quota tree or an individual user's usage within those quota trees. This information will hopefully be made available through a script that will use SNMP to check those limits in real-time.)
From any Unix machine where the /home/users and /home/projects directories are available, you can use the "quota" command to check your disk usage:
% quota -v yourusername
The output will look something like:
[skeezics@state:~] 14% quota -v skeezics
Disk quotas for skeezics (uid 1842):
Filesystem usage quota limit ...
/home 119792 1048576 1048576 ...
/disk/hopper/users
119792 1048576 1048576 ...
/disk/hopper/share
119792 1048576 1048576 ...
/disk/hopper/arch
119792 1048576 1048576 ...
The number that counts is the one for "/disk/hopper/users" -- that's where your home directories are stored. (On a minimally supported Unix machine this may not be the case, depending on how the mounts are done.)
In the above example, 'skeezics' is using roughly 120MB of space, with a hard limit of 1GB.
In your home directory there are often things that you overlook that can be significant consumers of disk space:
Browser cache
A preferences setting of 2MB memory cache and 2-5MB disk cache is a reasonable maximum when running Firefox on a shared machine like state. If you have set your disk cache higher than this, consider reducing it.
Note: You can clear Firefox's cache while it's running by going to Preferences->Privacy->Cache and hitting the "Clear" button.
core
If you've had a program crash and leave a core dump in your home directory, these can be quite large. Unless you specifically need that core image to do some debugging, there's no need to keep it.
Some people make a symlink to /dev/null named "core," and some people configure their preferred shell to limit the size of core files. Or, you can just remove core files whenever you notice them.
Directories named old_home_directory_from_*
These are artifacts from the great home directory migration that consolidated home directories from all of the old NFS servers to the NetApp ("hopper"). The long, annoying names where chosen on purpose so that they would stand out in directory listings and prod you into dealing with them. If you still have any left, then obviously you have a higher-than-normal tolerance for sloppy 'ls' aesthetics.
Often these directories contain data that is long-forgotten, or you had a home directory on a machine that you didn't even know about and never used. Please go through these and either save, compress, or delete their contents.
Various network trash folders
CDE, Aufs, and possibly other desktop environments (or even your own collection of Unix aliases) have ways to drag files into a trash folder so that file can be retrieved if you change your mind. However, if you forget to ever empty the trash, these directories can get quite large.
Using the GUI that created them is probably the best way to empty the trash, but from the shell you can look for:
| Directory | Used by |
|---|---|
|
.dt/Trash/ Network Trash Folder/ .delfiles/ |
CDE Aufs The CSEE 'del/undel' aliases |
...and possibly others. The lesson is "take out the papers and the trash." Yakkity yak, don't talk back. :-)
Other "." files or logs
Check for "." files like .xsession-errors or .xsession.log (the standard CSEE startup environment uses these) and make sure they haven't grown to ridiculous proportions without your noticing.
There are times when an X terminal will crash and leave some program spewing endlessly into an error log -- these can eat up space very quickly. Any program you run that logs to a file like this (procmail is a good example) can potentially create megabytes of output that you won't normally notice.
Check also for .dt/{errorlog,startlog,sessionlogs/} -- for runaway CDE sessions -- and outgoing mail logs (varies according to mail agent).
If you're building software in your home directory (or in your projects space, for that matter) and get the particular package to compile and install cleanly, please consider the temporary files you left behind. There may be valid reasons for keeping intermediate files around -- but for the most part, "make clean" is a good way to remove uneeded files. Be sure to read the makefile first, of course. :-)
The gzip program -- and its close relations gunzip, zcat, and zmore -- can help you lower your disk usage without forcing you to delete files.
Running gzip is a simple matter of pointing it at a file:
% gzip bigfile
The resulting file will be named bigfile.gz. It will likely be anywhere from 25% - 75% smaller than the original bigfile; the rate of compression depends on what type of file bigfile was in the first place. Returning it to its precompressed state is just as simple:
% gunzip bigfile
Similarly, you can zip up all the files in a directory (and its subdirectories) by using gzip with the -r (for "recursive") switch:
% gzip -r dir_of_big_files/
To become the command-line guru, see the tar man page.
Windows users can investigate WinZip or PKZip -- but beware: These are commercial programs, and dealing fairly with the vendors requires that your wallet be open.
Before you start randomly blowing away files, please be sure you aren't being too aggressive and removing things you'll need later. Wildcards can certainly bite you if you aren't careful. Fortunately, the NetApp can sometimes rescue you in these situations.
OHSU :: OGI :: CSEE :: Support :: CSEE :: Unix
This page was most recently revised on February 03, 2006.
Please address questions or comments to the webmaster.