home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / unix / bsd / 10404 < prev    next >
Encoding:
Text File  |  1992-12-21  |  3.3 KB  |  75 lines

  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!pmafire!mica.inel.gov!ux1!fcom.cc.utah.edu!cs.weber.edu!terry
  3. From: terry@cs.weber.edu (A Wizard of Earth C)
  4. Subject: Re: Dumb Question: Why 512 byte block?
  5. Message-ID: <1992Dec18.235623.27538@fcom.cc.utah.edu>
  6. Sender: news@fcom.cc.utah.edu
  7. Organization: Weber State University  (Ogden, UT)
  8. References: <1992Dec18.005050.20594@decuac.dec.com> <1992Dec18.030833.7395@fcom.cc.utah.edu> <1gt736INNjje@menudo.uh.edu>
  9. Date: Fri, 18 Dec 92 23:56:23 GMT
  10. Lines: 63
  11.  
  12. In article <1gt736INNjje@menudo.uh.edu> wjin@cs.uh.edu (W. Woody Jin) writes:
  13. >In article <1992Dec18.030833.7395@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
  14. >>In article <1992Dec18.005050.20594@decuac.dec.com>, darryl@vfofu1.dco.dec.com (Darryl Wagoner) writes:
  15. >>|> Why is everything in 1/2 k block instead the BSD standard of 1024 byte blocks?
  16. [ ... ]
  17. >>
  18. >>If I have a set of 6 512 byte files, I will use up 3K of disk for them;
  19. >>similarly, if I had a blocking factor of 1K, I would use of 6K (since the
  20. >>smallest fragment usable by a file is now 1K.
  21. >>
  22. >>If I have 6 1.5K files, this translates to 9K of disk(512B) or 12K of disk(1K).
  23. >>Obviously, if I have 6 1.6K files, both blocking factors take up 512K.
  24. >
  25. >I did not think that Fast Unix File System works this way.
  26. >If you have 6 1.5K files using 1K blocks,
  27. >   6 1k blocks will take each 1K from each file, and 
  28. >   3 1k blocks will take 0.5k from each file.
  29. >This was my understading from the famous FUFS paper.
  30.  
  31. You can't split blocks between files.  A block is, by definition, the
  32. smallest possible allocation unit.  Thin about the case where you have
  33. a 1 byte file and a 1 block - 1 byte file; what would you do when
  34. adding one or two characters to the first (1 Byte)?  TReallocate?  Shift
  35. and reallocate for the last byte of the second file?
  36.  
  37. But... you're right that it doesn't work the way I've shown... thought
  38. for sure I'd get bombarded on this one:
  39. >>Obviously, if I have 6 1.6K files, both blocking factors take up 512K.
  40. should have read:
  41. >>Obviously, if I have 6 1.6K files, both blocking factors take up 12K.
  42.  
  43. 1.6K rounded to a both a 512b and 1K boundry is 2K, and 2k * 6 = 12k.
  44.  
  45. >>When you store a lot of little files on the disk, small blocks are wasteful
  46. >>of disk space (for instance, 1024 empty files take 512K vs 1M of disk for
  47. >>the smaller blocking factor).
  48. >
  49. >And choosing a disk block size is a performance issue rather than
  50. >disk space issue. One should tune disk block size and fragment size
  51. >to get the best performance.
  52. >
  53. >I thought that 386BSD uses this Fast Unix File System.
  54.  
  55. Consider the most ridiculous possible situation:  I have a 1G disk with
  56. a 1G blocking factor (impossible without rewriting the buffering code).
  57.  
  58. How many files can I have on the disk? (Ignore the blocks allocated to inodes
  59. and directoryies 8-P).
  60.  
  61. The answer is "1"... even if it only has 1 byte in it.
  62.  
  63.  
  64.                     Terry Lambert
  65.                     terry@icarus.weber.edu
  66.                     terry_lambert@novell.com
  67. ---
  68. Any opinions in this posting are my own and not those of my present
  69. or previous employers.
  70. -- 
  71. -------------------------------------------------------------------------------
  72.                                         "I have an 8 user poetic license" - me
  73.  Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
  74. -------------------------------------------------------------------------------
  75.