home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / dec / 7165 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  1.7 KB
  1. Xref: sparky comp.sys.dec:7165 comp.unix.ultrix:9537
  2. Path: sparky!uunet!ukma!cs.widener.edu!dsinc!ub!niktow!pavlov
  3. From: pavlov@niktow.canisius.edu (Greg Pavlov)
  4. Newsgroups: comp.sys.dec,comp.unix.ultrix
  5. Subject: Re: "gnode: table is full" and "File table overflow"
  6. Message-ID: <1996@niktow.canisius.edu>
  7. Date: 28 Jan 93 09:37:40 GMT
  8. References: <1993Jan27.144336.14130@cs.hw.ac.uk>
  9. Followup-To: comp.sys.dec,comp.unix.ultrix
  10. Organization: Canisius College, Buffalo NY. 14208
  11. Lines: 25
  12.  
  13. In article <1993Jan27.144336.14130@cs.hw.ac.uk>, raz@cs.hw.ac.uk (Ross A Macintyre) writes:
  14. > Recently errors like these have been reported on our 5000/200.
  15. > These errors are reported by users and don't seem to appear in the error logger.
  16. > This was the output after "ls -l":
  17. > 
  18. > *bug.chk.sgi: File table overflow
  19. > *yp_pass.chk: File table overflow
  20.  
  21.   I would guess that you are running out of i/gnodes.  Reconfiguring your disk
  22.   to allow for more of them (smaller cylinder size, "-c" parameter in newfs,
  23.   or fewer bytes per inode, "-i" parameter) will USUALLY do the trick.  But 
  24.   note that most newfs parameters have rather limited ranges of possible 
  25.   settings that the man page doesn't bother telling you about.
  26.  
  27.   A grubby alternative: modify the configuration file by increasing "maxusers"
  28.   to some godawful amount, say 196 (196 ? why not ?  As good a number as any,
  29.   and one which I personally know to be "legal"), which hopefully increases
  30.   the size of kernel structures sufficiently to make the problem go away. You
  31.   might want to do this anyway, it's a useful palliative all around, like 
  32.   wearing garlic around your neck to keep the vampires away....
  33.  
  34.  
  35.  
  36.   greg pavlov
  37.   pavlov@fstrf.org
  38.