home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / aix / 9235 < prev    next >
Encoding:
Text File  |  1992-08-31  |  1.9 KB  |  46 lines
  1. Newsgroups: comp.unix.aix
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!osiris.usi.utah.edu!ben
  3. From: ben@osiris.usi.utah.edu (Ben Pratt)
  4. Subject: Re: JFS i-nodes summary
  5. Message-ID: <1992Aug31.210125.12123@fcom.cc.utah.edu>
  6. Keywords: jfs i-nodes filsystem
  7. Sender: news@fcom.cc.utah.edu
  8. Organization: Utah Supercomputing Institute
  9. References: <1992Aug28.174656.8854@fcom.cc.utah.edu> <1992Aug31.001843.16315@athena.mit.edu>
  10. Date: Mon, 31 Aug 92 21:01:25 GMT
  11. Lines: 33
  12.  
  13. In article <1992Aug31.001843.16315@athena.mit.edu> 
  14.     jfc@athena.mit.edu (John F Carr) writes:
  15.  
  16.   > 55 / 2000 = 2.8%
  17.   > 
  18.   > A loss of less than 3% of space merits an "ouch"?  If you're normally
  19.   > running at 97% capacity you've got bigger problems than JFS.
  20.   > 
  21.   > Have you investigated the performance of JFS as you approach 100% use?
  22.   > You may be better off not using the space.  The Berkeley fast file
  23.   > system reserves 10% in addition to the inode space to prevent
  24.   > performance degradation, but I rarely hear any complaints about
  25.   > inefficient use of space.
  26.   > 
  27.   > If you can get down to a small number of files of nearly constant size,
  28.   > you should not use JFS and instead use an unformatted disk partition
  29.   > (/dev/something).  This will have better performance and allow you to
  30.   > use more space.
  31.   > 
  32.   > --
  33.   >     John Carr (jfc@athena.mit.edu)
  34.  
  35. Thanks for the feedback, and the sanity check, John - your points are
  36. well taken.  I can say that in some cases, capacity is more important
  37. than performance (within reason) and that with 8 machines allocating
  38. close to half of a gig in unused i-nodes that could otherwise be used
  39. for datablocks, I don't like to see the unecessary waste.  If I want
  40. to sacrifice a little performance for the capability of writing 50
  41. more megabytes, why shouldn't I be able to?  That aside, I hadn't
  42. really considered the performance issue and appreciate your pointing
  43. it out to me,
  44.  
  45. Ben
  46.