home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / ibm / pc / hardware / 34149 < prev    next >
Encoding:
Text File  |  1992-12-24  |  3.4 KB  |  70 lines

  1. Newsgroups: comp.sys.ibm.pc.hardware
  2. Path: sparky!uunet!spool.mu.edu!agate!linus!linus.mitre.org!jcmorris
  3. From: jcmorris@mwunix.mitre.org (Joe Morris)
  4. Subject: Re: The maxtor 213 meg drive is NOT 213 megs!
  5. Message-ID: <jcmorris.725219398@mwunix>
  6. Sender: news@linus.mitre.org (News Service)
  7. Nntp-Posting-Host: mwunix.mitre.org
  8. Organization: The MITRE Corporation
  9. References: <s106275.725140761@ee.tut.fi> <1992Dec24.103209.21401@pasteur.Berkeley.EDU> <BzrLA1.D4C@cs.vu.nl> <1992Dec24.163552.3703@cc.gatech.edu>
  10. Date: Thu, 24 Dec 1992 17:49:58 GMT
  11. Lines: 57
  12.  
  13. duggan@cc.gatech.edu (Rick Duggan) writes:
  14.  
  15. >And all this talk of UNformatted capacity is driving me nuts.  Exactly
  16. >how much data can you store on an UNformatted drive?  Sound like 
  17. >0 bytes to me :-).  If you gotta format it to use it...
  18.  
  19. If you're limiting your discussion to PC-compatible environments, the
  20. unformatted capacity of a drive is not particularly meaningful except
  21. as a first-order approximation, to be used in comparison to other drives'
  22. unformatted capacity spec.
  23.  
  24. If you are referring to generic environments, or to computer systems which
  25. allow the user to specify the physical record lengths of data on a disk,
  26. then the "unformatted" capacity is a valid measure of the *maximum* 
  27. amount of data which can be stored.  Until the length of the recorded
  28. data blocks is specified, it's the only valid measure of the disk capacity.
  29.  
  30. Of course, you will achieve the maximum value only if every track on
  31. the drive is formatted to contain exactly one record, and that record
  32. has a length equal to the entire track.  Whenever you start formatting
  33. a track to contain more than one physical record, you will lose some
  34. of the capacity of the drive.  The track will still have the same number
  35. of bytes of data, but some of them are now allocated to the inter-record
  36. gap (IRG), others to the record headers used by the disk to locate the 
  37. data records, and still others to checksums and other administrative
  38. overhead.  The number of bytes lost in this way is a function of the
  39. design of the disk and its controller.
  40.  
  41. As an example, most IBM mainframe disks allow the user to specify the
  42. physical blocksize of the data on the disk.  For a 3380 disk, each
  43. track has a maximum unkeyed record length of 47476 bytes...but look
  44. at what happens when you start subdividing the real estate:
  45.  
  46.        Record      # of equal-size      Usable
  47.         size       records per track     bytes
  48.       --------         -----            ------
  49.         47476             1              47476
  50.          9076             5              45480
  51.          4276            10              42760
  52.          2164            18              38952
  53.  
  54. Formatting the track for 512-byte records would allow 46 records per
  55. track, for a track capacity of 23552 bytes...about a 50% loss from the
  56. unformatted capacity.
  57.  
  58. The comparison isn't completely valid because the mainframe disk has
  59. to provide functions not necessary on a desktop system where the
  60. block (= "sector") sizes are immutably fixed, but you can see that
  61. the overhead associated with each block can quickly consume a lot of
  62. the "unformatted" capacity when you format for small record sizes.
  63.  
  64. Now, if we can convince MS to allow DOS to talk (in native mode) to a 
  65. physical disk whose sectors are equal to the cluster size (say, 2048
  66. bytes for a typical hard disk today) then the amount of usable space would
  67. go up by some amount for a disk of given unformatted capacity.
  68.  
  69. Joe Morris
  70.