home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / unix / bsd / 10345 < prev    next >
Encoding:
Text File  |  1992-12-20  |  3.2 KB  |  68 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.030833.7395@fcom.cc.utah.edu>
  6. Sender: news@fcom.cc.utah.edu
  7. Organization: University of Utah Computer Center
  8. References:  <1992Dec18.005050.20594@decuac.dec.com>
  9. Date: Fri, 18 Dec 92 03:08:33 GMT
  10. Lines: 56
  11.  
  12. In article <1992Dec18.005050.20594@decuac.dec.com>, darryl@vfofu1.dco.dec.com (Darryl Wagoner) writes:
  13. |> Why is everything in 1/2 k block instead the BSD standard of 1024 byte blocks?
  14. |> Yes, I know there is a '-k' switch, but it seems to me it should be
  15. |> the otherway around.
  16.  
  17. Think of disk blocks as the curve-fitting algoritm they taught you when you
  18. first learned integral calculus:  the smaller your slices, the closer you
  19. come to approximating the area under the curve.
  20.  
  21. If I have a set of 6 512 byte files, I will use up 3K of disk for them;
  22. similarly, if I had a blocking factor of 1K, I would use of 6K (since the
  23. smallest fragment usable by a file is now 1K.
  24.  
  25. If I have 6 1.5K files, this translates to 9K of disk(512B) or 12K of disk(1K).
  26. Obviously, if I have 6 1.6K files, both blocking factors take up 512K.
  27.  
  28. The offset into the disk is a _block_offset_; what this means is that you
  29. will start looking for data at the offet*blocking_size when given an address,
  30. and that reads/write into kernel cache are done (usually) in block_size
  31. increments.  A device accessed this way is a blocked device.
  32.  
  33. When you store a lot of little files on the disk, small blocks are wasteful
  34. of disk space (for instance, 1024 empty files take 512K vs 1M of disk for
  35. the smaller blocking factor).
  36.  
  37. When you store a few large files on the disk, it is better to eat the 0 to
  38. 1K-1B penalty for each file (as opposed to the 0 to 511B for the small
  39. blocking factor) in trade for increased speed of access for the drive.
  40.  
  41. Since the typical 386BSD installation is a *large* number of files, it makes
  42. sense to trade speed of access for storage space.
  43.  
  44. If you are planning on attaching a large drive, you will want to up the
  45. blocking factor when you mkfs it, unless you make multiple partitions, since
  46. there is a limiting calculation which will prevent >1G drives from working
  47. well at a 512B block size.  Other than that, most modern drives, and most
  48. modern controllers supporting scatter/gather operations in hardware tend to
  49. lessen the impact of blocking on the drives (although significant speedups
  50. can be had by mucking with cylinder group sizes).
  51.  
  52. Some modern file systems allow you to dynamically change blocking factor,
  53. and even interleave, as you are writing the disk; for these file systems,
  54. there is usually a utility called "tunefs" to adjust things for all subsequent
  55. writes.
  56.  
  57.  
  58.                     Terry Lambert
  59.                     terry@icarus.weber.edu
  60.                     terry_lambert@novell.com
  61. ---
  62. Any opinions in this posting are my own and not those of my present
  63. or previous employers.
  64. -------------------------------------------------------------------------------
  65.                                         "I have an 8 user poetic license" - me
  66.  Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
  67. -------------------------------------------------------------------------------
  68.