[Info-vax] What is preserved by BACKUP/IMAGE/NOIINIT?

[abrsvc]

On Feb 13, 2:26 pm, hel... at astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> Just to be on the safe side, before booting one of my former satellites
> from a copy of the system disk, I decided to make a backup of it.  Since
> the output volume was properly initialised, I went for /NOINIT,
> especially since I wasn't sure if the /HEADERS value on the input volume
> is high enough for the future.  (I would then boot from the copy.)
>
> I got some messages telling me that the expansion size limit and logical
> volume size on the output volume would not be preserved.  (Actually, I
> don't expect them to change, since I had used SET VOLUME (see earlier
> post) to set them on the input volume; also, the disks are exactly the
> same size.)  Presumably, like with DEFINE in all tables but cluster-wide
> ones, the message that the value will be overwritten is displayed
> without checking if the value is the same.  (With DEFINE, the situation
> is probably slightly different, i.e. if the old and new values are the
> same, then no redefinition is done, probably to save overhead.)
>
> Also, HELP says:
>
>      Beginning in OpenVMS Version 7.2, when you use the BACKUP/IMAGE
>      command to restore or copy a volume, the BACKUP utility preserves
>      the cluster factor.
>
> This leads to the following questions:
>
> Why the change with 7.2 mentioned above?
>
> What, exactly, is preserved with BACKUP/IMAGE/NOINIT?
>
> Is there anything which is NOT preserved with BACKUP/IMAGE/INIT?

I seem to recall that the /init for a disk larger than the input
volume would result in the default cluster factor for the output
disk.  This would only be a factor when the target disk was
significantly larger than the input one. (eg. 2Gig copied to a 36Gig
drive).  There were restrictions to the size of the bitmap which would
prevent the larger disks from using small cluster sizes because the
number of clusters would exceed the max.  That went away a while ago
(maybe 7.2?)

Dan