home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / hp / 10355 < prev    next >
Encoding:
Internet Message Format  |  1992-09-13  |  2.0 KB
  1. Path: sparky!uunet!pmafire!news.dell.com!swrinde!zaphod.mps.ohio-state.edu!rpi!scott.skidmore.edu!psinntp!psinntp!polari!lampi@polari.online.com
  2. From: lampi@polari.online.com
  3. Newsgroups: comp.sys.hp
  4. Subject: Re: Disk Array & 2GB HP-UX limit
  5. Summary: This is a bogus limit IMHO
  6. Message-ID: <1992Sep12.005322.3016@polari>
  7. Date: 12 Sep 92 00:53:22 GMT
  8. References: <51980002@hpsgm2.sgp.hp.com> <BuBwMI.MFC@cup.hp.com>
  9. Organization: R Squared, Redmond, WA (206) 883-3116
  10. Lines: 36
  11.  
  12. In article <BuBwMI.MFC@cup.hp.com> markd@cup.hp.com (Mark_Donohoe) writes:
  13. >Raj PUBALA (klitd@hpsgm2.sgp.hp.com) wrote:
  14. >: Looking at the HP Disk Arrays data sheet, I see that with four disk drives
  15. >: in the array, we offer 5.4 GB of storage. 
  16. >: 
  17. >: I also read about the LVM (Logical Volume Manager) in HP-UX 9.0, which 
  18. >: says the size of a LV is still limited to 2GB which is the HP-UX
  19. >: system limitation.
  20. >: 
  21. >: Can anybody tell me whether HP Disk Arrays management can overcome this
  22. >: 2GB HP-UX system limitation?
  23. >: 
  24. >: If not, is there any suggestion on how to handle a file system ( which
  25. >: has no sub-directory ) which will grow beyond 2GB?
  26. >: 
  27. >
  28. >Yes, I have configured the LVM to be a 3.9Gig file system on HP-UX
  29. >9.0.  BTW, 4gig is the bigest that HP-UX can support at this time,
  30. >(you actually end up with a little less than 4 gig because of LVM and
  31. >other over head.)  It will take 64 bit pointers to address more in the
  32. >file system.
  33. >
  34. Why would it take 64 bit pointers to address >4GB file systems? After all,
  35. we're not necessarily talking about >4GB *files* (which would require
  36. such pointers), we're talking about >4GB *volumes*. It's really a stupid
  37. limitation that should have nothing to do with the 32 bit limit of
  38. pointers. After all, we're not talking about a pointer based from the
  39. beginning of the logical volume when we address the contents of a given file.
  40.  
  41. Or are we? :-)
  42.  
  43. -- 
  44. -----
  45. +-+  Michael Lampi       lampi@polari.online.com
  46. |R|  R Squared           16398 NE 85th St., Suite 101, Redmond, WA 98052
  47. +-+                      (206) 883-3116       fax (206) 883-2676
  48.