home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / bsd / 2899 < prev    next >
Encoding:
Internet Message Format  |  1992-07-26  |  2.2 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!wupost!zaphod.mps.ohio-state.edu!uunet.ca!cognos!dealwisb
  2. From: dealwisb@cognos.com (Brian de Alwis)
  3. Newsgroups: comp.unix.bsd
  4. Subject: Re: extract etc01 problem?
  5. Summary: negative values in df(1) reports
  6. Message-ID: <1992Jul26.144325.20251@cognos.com>
  7. Date: 26 Jul 92 14:43:25 GMT
  8. References: <HUDGENS.92Jul25181644@sun13.SCRI.FSU.EDU> <1992Jul26.095910.29737@Urmel.Informatik.RWTH-Aachen.DE>
  9. Organization: Cognos Incorporated, Ottawa CANADA
  10. Lines: 35
  11.  
  12. In article <1992Jul26.095910.29737@Urmel.Informatik.RWTH-Aachen.DE> kuku@acds.physik.rwth-aachen.de writes:
  13. >>extract:  etc01.xx : open:  too many open files
  14. >>
  15. >I got this same problem with etc01. When I looked at 'df's' output I saw
  16. >that my disk had run full  free -18619  106% (maybe the negative number is not
  17. >a bug but a feature?)
  18.  
  19. BSD's FFS reserves (by default) 10% of each disk to aid in allocating
  20. contiguous blocks for files. Once this 10% is reached, only root is
  21. allowed to allocate further files. The percentage and avail fields in
  22. df are actually reported as compared the remaining 90% of the disk.
  23. So, if you have 92000 blocks allocated, and your disk has 100000
  24. blocks (of which 10%=10000blks are 'reserved'), df would report that
  25. there were -2000 blocks, or 102%, free. See df(1) as well.
  26.  
  27. The errors extracting the etc01 distribution are because extract
  28. simply cat(1)'s all of the etc01.* files into a pipe - but as
  29. distributed, cat(1) does not close each file-descriptor when finished
  30. with the file [at least, this is what I gather from previous msgs
  31. about this]. A solution may be to do the extract yourself:
  32.  
  33. for i in /tmp/etc01.*; do cat $i; done | uncompress | cpio -idalmu
  34.  
  35. (in Bourne shell - I don't like or use C-shell) This should close each
  36. file after cat(1)'ting it, but will be much slower (you'll be running
  37. 60-odd cat(1) processes sequentially).
  38.        This problem is because the default maximum-of-open-files per
  39. process is 64 - three are already taken used as std{in,out,err},
  40. leaving only 61.
  41.  
  42. Hope this helps.
  43. -- 
  44. +++BdA  Brian de Alwis. Brain on loan to Cognos Inc, Ottawa, Ontario.
  45.     dealwisb@cognos.com, or bsdealwi@napier.{waterloo.edu,uwaterloo.ca}
  46.     "Nine out of ten men who tried camels said they preferred women"
  47.