home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / vms / 19619 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  1.8 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: re: Re: BINDING System disk to another disk
  5. Message-ID: <9212210248.AA18228@uu3.psi.com>
  6. Date: 21 Dec 92 01:36:58 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 30
  11.  
  12.  
  13.     [An earlier message looked for a way to make the system disk a member
  14.     of a bound volume set.  Carl Lydick comments:]
  15.     The system disk CANNOT be part of a bound volume set.  Period.
  16.  
  17. A little more detailed discussion is in order.
  18.  
  19. Assuming you have some other disk to boot off of so that you can avoid
  20. mounting your normal system disk, it is trivial to take an existing system
  21. disk and make it part of a volume set.  The resulting disk will boot and
  22. run normally - but it contains a hidden time bomb.  One of these days,
  23. the system software will be upgraded, or some essential system file will be
  24. re-created for some other reason.  And all of a sudden the system will be
  25. found to be unbootable.
  26.  
  27. Why?  The boot code knows how to mount and use a single system disk.  It
  28. hasn't any idea how to mount multiple members of a bound volume set.  As
  29. long as EVERY file needed during the boot process (up to the point where
  30. enough of the system is up for you to issue a MOUNT command for the second
  31. volume, which is actually quite late) is on the first member of the volume
  32. set, everything will work.  But you don't, in general, control where on a
  33. volume set files - and even directories - are placed.  As soon as some
  34. essential file ends up on the second volume, bye bye system.
  35.  
  36. People have run systems in this configuration.  It's extremely fragile, and
  37. completely unsupported - but that doesn't mean people haven't done it.  I
  38. would, however, advise strongly against it.
  39.  
  40.                             -- Jerry
  41.  
  42.