home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / hp / 10411 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  2.3 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!spool.mu.edu!sdd.hp.com!apollo.hp.com!cupnews0.cup.hp.com!markd
  2. From: markd@cup.hp.com (Mark_Donohoe)
  3. Newsgroups: comp.sys.hp
  4. Subject: Re: Disk Array & 2GB HP-UX limit
  5. Message-ID: <BuLDpr.BDK@cup.hp.com>
  6. Date: 14 Sep 92 23:39:27 GMT
  7. References: <1992Sep12.005322.3016@polari>
  8. Sender: news@cupnews0.cup.hp.com
  9. Organization: Hewlett-Packard
  10. Lines: 38
  11. X-Newsreader: Tin 1.1.3 PL5
  12.  
  13. lampi@polari.online.com wrote:
  14. : In article <BuBwMI.MFC@cup.hp.com> markd@cup.hp.com (Mark_Donohoe) writes:
  15. : >Raj PUBALA (klitd@hpsgm2.sgp.hp.com) wrote:
  16. : >: Looking at the HP Disk Arrays data sheet, I see that with four disk drives
  17. : >: in the array, we offer 5.4 GB of storage. 
  18. : >: 
  19. : >: I also read about the LVM (Logical Volume Manager) in HP-UX 9.0, which 
  20. : >: says the size of a LV is still limited to 2GB which is the HP-UX
  21. : >: system limitation.
  22. : >: 
  23. : >
  24. : >Yes, I have configured the LVM to be a 3.9Gig file system on HP-UX
  25. : >9.0.  BTW, 4gig is the bigest that HP-UX can support at this time,
  26. : >(you actually end up with a little less than 4 gig because of LVM and
  27. : >other over head.)  It will take 64 bit pointers to address more in the
  28. : >file system.
  29. : >
  30. : Why would it take 64 bit pointers to address >4GB file systems? After all,
  31. : we're not necessarily talking about >4GB *files* (which would require
  32. : such pointers), we're talking about >4GB *volumes*. It's really a stupid
  33. : limitation that should have nothing to do with the 32 bit limit of
  34. : pointers. After all, we're not talking about a pointer based from the
  35. : beginning of the logical volume when we address the contents of a given file.
  36. : 
  37. : Or are we? :-)
  38. : 
  39. I don't think it is reasonable to limit files as such.  If you need >4Gig
  40. then you MIGHT just have a file bigger than 2gig, in which case you need the
  41. larger pointer.  Secondly, as hinted at, it is IMHO better to have a general
  42. solution that does not restrict things.  What you suggest is that you could
  43. support a file system greater than 4gig, but no file could be bigger than
  44. 2gig....not very general if you ask me.  Especially since memory will be
  45. greater than 2gig very soon (think of a >2gig OS core dump to wade through!).
  46.  
  47. anywho, that is what is supported now and possible.  Thought the original
  48. poster might want to know.
  49. --
  50. Mark Donohoe (markd@cup.hp.com)
  51.