home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / ultrix / 5794 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.3 KB
  1. Path: sparky!uunet!olivea!decwrl!pa.dec.com!nntpd2.cxo.dec.com!nntpd.lkg.dec.com!amber!cavedog.athena.lkg.dec.com!mamros
  2. From: mamros@athena.lkg.dec.com (Shawn Mamros)
  3. Newsgroups: comp.unix.ultrix
  4. Subject: Re: Two questions from Ultrix novice
  5. Message-ID: <790982@athena.lkg.dec.com>
  6. Date: 21 Jul 92 13:31:50 GMT
  7. References: <1992Jul20.150115.2701@ctr.columbia.edu>
  8. Sender: mamros@cavedog.athena.lkg.dec.com (Shawn Mamros)
  9. Reply-To: mamros@athena.lkg.dec.com (Shawn Mamros)
  10. Organization: Digital Equipment Corporation
  11. Lines: 34
  12.  
  13.  
  14. shenkin@avogadro.barnard.columbia.edu (Peter S. Shenkin) writes:
  15. >1.  The "df" command is not properly displaying disk utilization.  If I
  16. >    add large files, the command properly tells me that more kbytes are
  17. >    used and fewer are free;  however, if I remove large files df exhibits 
  18. >    no change.  The net effect is that as the system ages "used" eventually 
  19. >    gets to 100% according to df, despite the fact that there is plenty of 
  20. >    space on disk.  Rebooting updates the display.
  21. >
  22. >    What's broken, and how can I fix it?
  23.  
  24. What's almost certainly happening here is that a process still has the
  25. file open when you remove it.  The system can't reclaim the disk space
  26. which a file takes up until *all* references to the file are gone - not
  27. only all directory entries ("links") to the file, but also any open file
  28. descriptors to that file that a process may have.  This is why rebooting
  29. "fixes" the problem - the process(es) which have that file open is/are no
  30. longer around.
  31.  
  32. A classic example of this is a daemon process which maintains its own log
  33. file.  Most daemons won't open/close a log file every time they want to
  34. write a new entry to it - they'll just open it once at startup time, and
  35. keep it open.  When you remove the log file, the daemon still has it open,
  36. and the space the file takes up won't be made available until the daemon
  37. closes it or until the daemon is killed.  Depending on which file it is
  38. (and which daemon is responsible), you might be able to SIGHUP the daemon
  39. and have it close the old log file and open a new one with the same filename,
  40. without having to stop the daemon altogether.
  41.  
  42. Nothing is broken - that's just the way the filesystem is designed to work.
  43. It ensures programs that an opened file won't be wiped away from underneath it.
  44.  
  45. -Shawn Mamros
  46. E-mail to: mamros@athena.lkg.dec.com
  47.