home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / hp / 9962 < prev    next >
Encoding:
Text File  |  1992-09-02  |  2.0 KB  |  48 lines
  1. Newsgroups: comp.sys.hp
  2. Path: sparky!uunet!netnews!warper.jhuapl.edu!trn
  3. From: trn@warper.jhuapl.edu (Tony Nardo)
  4. Subject: Re: Third party disk drives on HP-UX
  5. Message-ID: <trn.715435022@warper.jhuapl.edu>
  6. Sender: usenet@netnews.jhuapl.edu
  7. Organization: JHU/Applied Physics Laboratory
  8. References: <1992Aug29.191511.29259@riacs.edu> <7371283@hpfcso.FC.HP.COM>
  9. Date: Wed, 2 Sep 1992 11:57:02 GMT
  10. Lines: 36
  11.  
  12. kinsell@hpfcso.FC.HP.COM (Dave Kinsell) writes:
  13.  
  14. |In comp.sys.hp, trn@warper.jhuapl.edu (Tony Nardo) writes:
  15.  
  16. |> >  (2) What problems did you encounter?
  17. |> 
  18. |> I lost roughly 7% of the usable space on my disk due to the assumption by
  19. |> HP that all drives will have 1024-byte sectors.  They provide a workaround
  20. |> solution for those who have 512-byte sectors so that you may still use the
  21. |> drive.  However, a disk with an odd number of 512-byte tracks will lose one
  22. |> track under the workaround.
  23. |>
  24. |
  25. |You specify disk geometry in terms of 1024 byte units, but that causes no loss
  26. |of capacity for the drive.  I suspect your 7% loss came from file system
  27. |overhead, primarily inodes, which can be adjusted if desired.
  28.  
  29. My apologies.  Looking at the number of free inodes per disk, I see that the
  30. disk on the Sun must have been configured with roughly one inode per 4096 bytes,
  31. vs. the default of one per 2048.
  32.  
  33. |You also need
  34. |to realize that disk vendors specify decimal megabytes, whereas utilities
  35. |like bdf use units of 1024 in reporting capacities.
  36.  
  37. Using Berekley-df (bdf), the kbyte capacity of the drive in question (on a
  38. Sun) is 1314173.  The same model drive on the HP, using bdf, reports a kbyte
  39. capacity of 1221949.  That's where my 7% figure came from.  In hindsight, if
  40. the missing track was the sole culprit, I should have expected a difference
  41. of ~5.9%.  1/17 sounded close enough to 7% that I assumed the problem lay in
  42. the loss of one track's data.
  43.  
  44. Oh, well, another shot in the ol' foot... :-)
  45. --
  46. Tony Nardo,           INET: trn@warper.jhuapl.edu, trn@aplcomm.jhuapl.edu
  47.  Johns Hopkins Univ./APL   UUCP: {backbone!}mimsy!aplcomm!trn
  48.