[Info-vax] image backup on itanium

[Stephen Hoffman]

On 2015-05-03 03:47:25 +0000, Michael Moroney said:

> JF Mezei <jfmezei.spamnot at vaxination.ca> writes:
> 
>> In the proposed COPY, would it be correct to assume that
>> 1- backup/image DKA100: LDA1: (pointing to disk.iso
>> 2- mount/foreign  DKA200:
>> 4- copy disk.iso DKA200:
>> ?

Disk replication is discussed in <http://labs.hoffmanlabs.com/node/28> 
in some detail.

> Oh, I see what you are doing.  This will do a block by block copy, more 
> like BACKUP/PHYSICAL than anything else.
> 
>> If LDA1: has been created to have say 600 megs, and DKA200: has 1 gig.  
>>  Will the extra 400 megs be available after the COPY operation ?

By default, no.

> With a mismatched disk like that, there will be two problems.  First, 
> as you mention, BITMAP.SYS may not cover the whole drive.  You'll get a 
> warning upon mounting it.  $ SET VOLUME/LIMIT should fix it.  Second, 
> GPT.SYS has two parts, to cover the fake partition stuff.

In various cases, yes.

There are cases where the expansion will not be permitted, as some 
combinations of cluster size and disk expansion will blow out the 
bitmap limits.

The GPT.SYS has two extents, intended to cover the blocks required for 
the GPT partitioning table; the disk volume partitioning data.  It's 
OpenVMS that's faking out things here, not the partitioning.  OpenVMS 
does not have partitioning support, so some really ugly hackery was 
used to allow ODS-2 and ODS-5 to coexist on a GPT disk.

> The  first part is at the very beginning.  The second part will be at 
> the very end.

The primary and backup GPT.   The primary GPT is at the lowest sectors 
of the disk.  The secondary or backup GPT is at the highest range of 
sectors.  The two GPTs contain pointers to each other, and are 
theoretically used to repair each other.   The pointers must be 
consistent, but most firmware only goes looking for the secondary GPT 
if the primary fails to verify.   Unfortunately, with the use of DVE, 
the backup GPT can end up located somewhere other than at the highest 
blocks of the disk.  The Intel folks were surprised disks could be 
expanded online on some systems, and their EFI design does not 
particularly reflect that possibility.  AFAIK, OpenVMS does not 
presently properly reserve the highest-numbered sectors at the end of 
the disk after a DVE operation (as it probably should) and does not 
recreate and adjust the GPT linkages (as it probably should) — though 
I've not checked this in a while, either.   Having the GPT not at the 
end of the disk does work, so long as the primary GPT is not corrupted.

> With your COPY trick, the end cluster will be misplaced.

End clusters are often screwed up when this sort of thing happens, and 
it'll flag errors in the analysis operations but will normally boot, 
assuming other issues (below) are resolved.   Various of the OpenVMS 
VAX and OpenVMS Alpha distribution CD disks have had these 
"corruptions" latent, for instance.

> I don't think this affects booting.  I don't know what is in that 
> second cluster.

While the GPT is potentially variable in size, it's a fixed (minimal) 
size on OpenVMS.  It is not a fixed number of clusters.

You could, of course, read the document previously linked.  Then you 
would understand rather more about the boot structures and related 
commands and operations.

> 
>> When mounted normally, will VMS update disk structures to reflect the 
>> fact that the disk has 400 extra megs available ? (thinking about 
>> bitmap.sys and other ODS files)
> 
> No, other than any leftover space in BITMAP.SYS (partially used last 
> cluster) MAY be allocated/used. It won't be extended to cover the disk.

You'll get errors, but it'll usually work.

As was asked else-thread, the block offset requirements involve a SET 
BOOTBLOCK command; bootable disks are specific to the target device 
sector size.  A disk will not (by default) boot on a different medium.  
A copy of a DVD image will not boot on a 512-byte sector legacy-format 
disk or a 4096-byte sector advanced-format disk (advanced is not yet 
supported by OpenVMS) without a SET BOOTBLOCK to correct the offsets.  
The tools will also report whether the operation is feasible, as it is 
possible for some sequences to produce disks that are not aligned — 
copying 512-byte disks to 2048-byte optical media only works reliably 
when the cluster sizes are a multiple of 2048 bytes.  Then you have to 
to contend with the boot aliases — removing and re-adding those will 
usually resolve the issues.

Again, all of this is detailed in the document I've linked.  
<http://labs.hoffmanlabs.com/node/28>



-- 
Pure Personal Opinion | HoffmanLabs LLC