home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / ultrix / 9076 < prev    next >
Encoding:
Internet Message Format  |  1992-12-24  |  2.5 KB
  1. Xref: sparky comp.unix.ultrix:9076 comp.unix.misc:4712
  2. Path: sparky!uunet!spool.mu.edu!yale.edu!jvnc.net!princeton!rutgers!micro-heart-of-gold.mit.edu!news.media.mit.edu!news.media.mit.edu.!nessus
  3. From: nessus@media.mit.edu (Douglas Alan)
  4. Newsgroups: comp.unix.ultrix,comp.unix.misc
  5. Subject: Re: Ultrix newfs/mkfs -- can't change number of inodes?!
  6. Message-ID: <NESSUS.92Dec24135609@twitch.media.mit.edu>
  7. Date: 24 Dec 92 18:56:09 GMT
  8. References: <BzFv8K.JEJ@mtholyoke.edu> <1992Dec20.094432.9276@pony.Ingres.COM>
  9. Sender: news@news.media.mit.edu (USENET News System)
  10. Organization: Kate Bush and Butthole Surfers Fandom Center
  11. Lines: 35
  12. In-Reply-To: rog@Ingres.COM's message of 20 Dec 92 09:44:32 GMT
  13.  
  14. > In article <1992Dec20.094432.9276@pony.Ingres.COM> rog@Ingres.COM
  15. > (Roger Taranto) writes:
  16.  
  17. >   If the block size is 8192, then the number of cylinders per group must
  18. >   be a multiple of 16, and the frag size must be at least 1024.
  19.  
  20. This is not really true.  This limitation only occurs for some disktab
  21. entries.  For other disktab entries, you can go down to a cylinder
  22. group size of 4 cylinders and maintain a block size of 8192.  The
  23. conclusion from this is that the disk geometry parameters that you
  24. give to newfs effect the minimum cylinder group size.  I've never
  25. determined the exact relationship here, but you can try giving newfs
  26. random disktab entries, until you find one that works.
  27.  
  28. "Doesn't giving newfs a random disktab entry mess up the fine tuning
  29. parameters for the filesystem and thus degrade performance?" you might
  30. ask.  Well, perhaps it does, but I've done a fair number of empirical
  31. tests and never noticed much of a differenence.  Something that has a
  32. much bigger effect it usually to up "maxcontig" using tunefs.  This is
  33. not done by default and can cause a significant performance increase.
  34. (it also might have no effect, or decrease performance if set too
  35. high, so you should do some measurements.)
  36.  
  37. You may think that setting the block size down to 4096 is a better
  38. alternative than messing up the fine tuning parameters.  This is
  39. probably not true.  The two most significant reasons for the good
  40. performance of the Berkeley Fast File System is the large block size
  41. and the fact that seeking distances are reduced by keeping most
  42. adjacent blocks in a file in the same cylincer group.  Reducing the
  43. block size to 4096 would be diminishing one of the most important
  44. sources of the filesystems performance gains.  The gains from the
  45. fine-tuning parameters are relatively minor in comparison.
  46.  
  47. |>oug
  48.    <nessus@mit.edu>
  49.