home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / aix / 11393 < prev    next >
Encoding:
Text File  |  1992-11-08  |  2.4 KB  |  55 lines
  1. Newsgroups: comp.unix.aix
  2. Path: sparky!uunet!utcsri!torn!utzoo!utdoe!torag!jrh!jrh
  3. From: jrh@jrh.uucp (James R. Hamilton)
  4. Subject: Re: /tmp Corrupted
  5. Message-ID: <1992Nov08.070150.196948@jrh.uucp>
  6. Organization: private system, Toronto, Ontario
  7. References: <1992Nov5.225824.3656@netcom.com>
  8. Date: Sun, 08 Nov 1992 07:01:50 GMT
  9. Lines: 44
  10.  
  11. In article <1992Nov5.225824.3656@netcom.com> lui@netcom.com (Stephen Lui) writes:
  12. >Recently our /tmp file system started to fill up. I went to /tmp and deleted
  13. >unnecessary files. However, this did not release any space in the file system
  14. >according to df. I went ahead and deleted all of the files in /tmp and the
  15. >file system was still 100% full! I ran fsck on /tmp and got:
  16. >
  17. >
  18. >** Checking /dev/hd3 (/tmp) MOUNTED FILE SYSTEM; WRITING SUPPRESSED; 
  19. >** Phase 1  - Check Blocks and Sizes
  20. >** Phase 2  - Check Pathnames
  21. >** Phase 3  - Check Connectivity
  22. >** Phase 4  - Check Reference Counts
  23. >** Phase 5  - Check Inode Map
  24. >The Inode map is not valid. (NOT SALVAGED)
  25. >** Phase 6  - Check Block Map
  26. >The Block map is not valid. (NOT SALVAGED)
  27. >The integrity of the file system is not guaranteed.
  28. >109 files 3576 blocks 37384 free
  29. >
  30. >To keep the system up, I created another /tmp file system and mounted it over
  31. >/tmp. After later rebooting the system and running fsck (you can't run fsck
  32. >and write to /tmp when it's mounted) the problem disappered. However, half a
  33. >day later the problem repeated itself.
  34. >
  35. >After a few days the problem seemed to correct itself. However, today the
  36. >same problem happened to /usr/ingres/files, a user-defined filesystem on a
  37. >total different physical disk. Any suggestions?
  38.  
  39.     Many program open tmp files and then unlink them.  The effect of doing
  40.     this is the file will not show up in the /tmp directory but it does
  41.     continue to take up space as long as the program is alive and the file
  42.     is open.  If the file is closed or the program terminates (due to any
  43.     reason) then the space is freed up.  I suspect that you can figure out
  44.     whether or not this is happening by attempting to un-mount the filesystem.
  45.     This will fail if a process has a file open in that file system.  
  46.  
  47.     Incidentally, fsck should not be run on a mounted file system.
  48.  
  49.                           --jrh
  50. -- 
  51.  
  52. James R. Hamilton                              inet: jrh@jrh.gts.org
  53. telephone: +1 416 493 4162                     uunet: ...!uunet!jrh!jrh
  54. Toronto, Canada                                work: jrh@torolab6.vnet.ibm.com
  55.