home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / admin / 4264 < prev    next >
Encoding:
Text File  |  1992-07-22  |  2.0 KB  |  46 lines
  1. Newsgroups: comp.unix.admin
  2. Path: sparky!uunet!stanford.edu!morrow.stanford.edu!news
  3. From: caroline@topaz.Stanford.EDU (Caroline Lambert)
  4. Subject: disk space strategy suggestion for small groups
  5. Message-ID: <1992Jul22.155816.10864@morrow.stanford.edu>
  6. Sender: news@morrow.stanford.edu (News Service)
  7. Organization: Stanford Univ. Earth Sciences
  8. Date: Wed, 22 Jul 1992 15:58:16 GMT
  9. Lines: 35
  10.  
  11. In light of the recent postings about how to tell users about
  12. full file systems, I thought I'd share my strategy for handling
  13. disk space problems.
  14.  
  15. The most common approach is to wait until the disk is full, and
  16. then send a message to the disk hogs telling them how much disk
  17. space they are using and to clean up. Or to post a list of the
  18. top disk hogs.
  19.  
  20. There are several inadequacies with this approach. First, I don't
  21. want the disks to ever get totally filled up. Second, many users 
  22. don't know enough about Unix to find all their files efficiently.
  23. Third, the user with 10 Mb of disk space that hasn't been touched
  24. in a year is more guilty than the person who filled up the disk
  25. with 100 Mb of new data yesterday, in my opinion.
  26.  
  27. Part of my strategy is to run a program that makes a list of
  28. each user's files that exceed a certain threshold in terms of
  29. both size *and* age, and then mails that list to the user, with
  30. a message asking them to look over the list and decide which files
  31. they really need to have on the system. The program is run from
  32. cron on a regular basis (not too often, or the message gets ignored,
  33. yet not too infrequently or the disk fills up).
  34.  
  35. This appears to work with my group, but I have only dozen or so 
  36. regular users, whom I know personally, so I have no idea how well
  37. it would work in a larger installation - I suppose with a larger
  38. number of users the program would use a significantly greater amount
  39. of resources generating the lists, and then the lists would clog
  40. the mail system. However, for small groups it's a suggestion.
  41.  
  42. --
  43. Caroline Lambert                  
  44. Seismic Tomography Project                caroline@topaz.Stanford.EDU
  45. Department of Geophysics, Stanford University    
  46.