home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / unix / ultrix / 8878 < prev    next >
Encoding:
Text File  |  1992-12-14  |  2.7 KB  |  69 lines
  1. Newsgroups: comp.unix.ultrix
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!haven.umd.edu!decuac!pa.dec.com!engage.pko.dec.com!nntpd.lkg.dec.com!nntpd2.cxo.dec.com!nabeth!alan
  3. From: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
  4. Subject: Re: Very large file systems ?
  5. Message-ID: <1992Dec14.214641.18792@nntpd2.cxo.dec.com>
  6. Lines: 56
  7. Sender: alan@nabeth (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
  8. Reply-To: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
  9. Organization: Digital Equipment Corporation
  10. References:  <johnd.723948393@cortex.physiol.su.oz.au>
  11. Date: Mon, 14 Dec 1992 21:46:41 GMT
  12.  
  13.  
  14. In article <johnd.723948393@cortex.physiol.su.oz.au>, johnd@cortex.physiol.su.oz.au (John Dodson) writes:
  15. >Newsgroups: comp.unix.ultrix
  16. >From: johnd@cortex.physiol.su.oz.au (John Dodson)
  17. >Subject: Very large file systems ?
  18. >
  19. >I just got a couple of Hitachi DK517C-37 scsi drives to go on my DecStn 5000/200
  20. >running Ultrix 4.2
  21. >
  22. >The drive reports its size as 5611599 * 512 byte blocks.
  23. >
  24. >Further testing produced...
  25. >
  26. >$ mkfs /dev/rrz0c 4194303
  27. >
  28. > [ Example deleted, but it is the clue to what is going on... ]
  29. >
  30. >What is so magic about "4194304" blocks ? AH! it's 2^22 !
  31. >
  32. >In the 4.3bsd sources for the fs struct...
  33. >    long    fs_size;                /* number of blocks in fs */
  34.  
  35. While the number of blocks is limited to the size of a signed long
  36. (ULTRIX has the same declaration: /usr/include/ufs/fs.h) programs
  37. like newfs(8), fsck(8), dump(8), etc must treat devices as files.
  38. As you noted in a later follow-up of your own, the "where" argument
  39. of lseek(2) is a 31 bit integer and largest offset within a file
  40. is limited to (2^31)-1 bytes.
  41.  
  42. >
  43. >so I should be able to have at least 2^31 (or even 2^32) blocks in a file
  44. >system, is Ultrix different ? or is Ultrix mkfs brain dead ?
  45. >or am I brain dead ? ;-)
  46.  
  47. You'll discover BSD has the same limitation as ULTRIX.  Some vendors
  48. have used the non-standard solution of inventing special seek functions
  49. that allow either larger offsets or do block addressing.  Another
  50. solution on 32 bit systems might be to make long and int be different
  51. size and use either emualation libraries or smarter compilers to
  52. provide the different code.  This would likely make long arithmetic
  53. slow.  I believe it was what used on the PDP 11s to support 32 bit
  54. longs and 16 bit ints.
  55.  
  56. It's worth noting that OSF/1 on Alpha AXP systems will use 64 integers
  57. for long and that the appropriate changes have been made to support
  58. large file and file system sizes.
  59. >
  60. >
  61. >John Dodson,                    Dept of Physiology,
  62. >johnd@physiol.su.oz.au                University of Sydney,
  63. >Phone    +61-2-692-3277                NSW 2006
  64. >Fax    +61-2-692-2058                Australia.
  65. >
  66. --
  67. Alan Rollow                alan@nabeth.cxo.dec.com
  68.  
  69.