home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / ultrix / 5799 < prev    next >
Encoding:
Text File  |  1992-07-21  |  3.1 KB  |  67 lines
  1. Newsgroups: comp.unix.ultrix
  2. Path: sparky!uunet!usc!sol.ctr.columbia.edu!avogadro.barnard.columbia.edu!shenkin
  3. From: shenkin@avogadro.barnard.columbia.edu (Peter S. Shenkin)
  4. Subject: Another question;  was: Re: Two questions from Ultrix novice
  5. Organization: Dept. of Chem, Barnard College, Columbia U, New York
  6. References: <1992Jul20.150115.2701@ctr.columbia.edu> <790982@athena.lkg.dec.com>
  7. Message-ID: <1992Jul21.162216.25343@ctr.columbia.edu>
  8. Sender: news@ctr.columbia.edu (The Daily Lose)
  9. Date: Tue, 21 Jul 1992 16:22:16 GMT
  10. X-Posted-From: avogadro.barnard.columbia.edu
  11. X-Posted-Through: sol.ctr.columbia.edu
  12. Lines: 53
  13.  
  14. In article <790982@athena.lkg.dec.com> mamros@athena.lkg.dec.com (Shawn Mamros) writes:
  15. >
  16. >shenkin@avogadro.barnard.columbia.edu (Peter S. Shenkin) writes:
  17. >>1.  The "df" command is not properly displaying disk utilization.  If I
  18. >>    add large files, the command properly tells me that more kbytes are
  19. >>    used and fewer are free;  however, if I remove large files df exhibits 
  20. >>    no change....
  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.....
  26.  
  27. This is almost certainly not the answer, though it was a reasonable guess.  
  28. The sysadm told me that this machine had this problem chronically.  To check 
  29. it out, after a reboot I did the following:
  30.  
  31.     1.  look at df output
  32.     2.  copy large file (actually, "cp -r dirname new_dirname")
  33.     3.  look at df output -- /usr has grown
  34.     4.  "/bin/rm -rf new_dirname" -- it's gone
  35.     5.  look at df output -- /usr has not changed in size
  36.     6.  reboot;  look at df output -- /usr has shrunk to original size
  37.     
  38. No processes were started to access the new files.  But please read on....
  39.  
  40. Now for the new question:  Yesterday a DEC field engineer showed up to
  41. replace tghe mother board in all our DecStation 5000's.  This action was
  42. initiated by DEC, and though the service guy didn't know exactly why
  43. they were  doing this, as well as he knew, it was a combination of (1)
  44. added RF shielding to meet FCC regulations, and (2) firmware rev to 
  45. fix some bugs that occur in some situations.
  46.  
  47. Following the board replacement my df problem went away.  However, a far
  48. more serious problem started:  the machine slowed down incredibly.  It
  49. seems to be thrashing all the time.  To login on the console it takes 30
  50. seconds for session manager to appear, and over an additional minute for
  51. DECterms to appear, then more time for them to respond -- all this
  52. accompanied by continuous disk chatter.
  53.  
  54. A set of about 12 Fortran files which, the previous day, had compiled in less
  55. than an hour, took far longer;  after 1-1/2 hour it still had not finished
  56. with the second .f file.  This was also accompanied by literally continuous
  57. disk chatter.
  58.  
  59. Can anyone help with diagnosing/fixing this problem?
  60.  
  61.     -P.
  62. -- 
  63. ************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb*************************
  64. Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027
  65. (212)854-1418    shenkin@avogadro.barnard.columbia.edu   shenkin@cunixf.BITNET
  66. ******************** The singular of "media" is "medium". ********************
  67.