Missing '/foreign' labels on image backups

[Shriniketan Bhagwat]

Hi,

Even I expect MOUNT/FOR to display the label of the disk.

$ mount/for UTIL$LDA1:
%MOUNT-I-MOUNTED, LD_DISK mounted on _UTIL$LDA1:
$

If the MOUNT/FOR command is not displaying the label, then what does the SHOW DEV dkb0: command display after the mounting the disk with /FOR qualifier?

Below are the sample commands with which you can read the label of the foreign mounted disk.
$
$ init UTIL$LDA1: LD_DISK
$ mount/for UTIL$LDA1:
%MOUNT-I-MOUNTED, LD_DISK mounted on _UTIL$LDA1:
$
$ dump/blo=coun=1 UTIL$LDA1:
Dump of device UTIL$LDA1: on 23-NOV-2010 08:02:18.52

Logical block number 0 (00000000), 512 (0200) bytes

8BDFFF76 905F0000 000501FB 000609F7 03039401 001E65C0 11C00200 15C600A0 ..F...@.@e......w...{....._.v._. 000000
73206120 746F6E20 73692020 20202020 2020204B 5349445F 444C0087 80FDFF74 t.}...LD_DISK is not a s 000020
00000000 00000000 00000000 00000000 0000000A 0A0D6B73 6964206D 65747379 ystem disk...................... 000040
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000060
â ¦
â ¦
â ¦
$ open/read x UTIL$LDA1:
$ read x record
$ label = f$extr(38,12,record)
$ show symbol label
LABEL = "LD_DISK "
$ close x
$ dismount UTIL$LDA1:
$

Regards,
Ketan

[Shriniketan Bhagwat]

Hi Jon,

>> Unfortuneately, the new disk will still have GPT.SYS mapping lbn 0-33.

BACKUP has been enhanced with /GPT qualifier recently to control the propagation of GPT.SYS from source to destination disk. This has been released as part of VMS84A_UPDATE-V0400 and VMS84I_UPDATE-V0400 kits.

Regards,
Ketan

[Jon Pinkley]

In my Nov 23, 2010 03:13:17 comment I said "However if we overwrite LBN 2 with all zeros (using DISKBLOCK)". That should have been LBN 1 (the first candidate location for a homeblock). The attachment had the correct info.

[Jon Pinkley]

Ketan,

Thanks for the info about updates to 8.4, but that won't help Ken (see his initial post).

Just for your information, what is in LBN 0 may look like the label, but it is just text put there by INITIALIZE.

Try the following and you will see that what is in LBN 0 is put there by the init command, but it isn't modified by the set volume /label command (which updates the homeblocks)

$ init util$lda1: itrc01
$ mou/for util$lda1:
$ dump/blo=(c:2) util$lda1: ! note that lbn 1 has the label
$ dism util$lda1:
$ mou/ov=id util$lda1:
$ set vol/lab=ketan util$lda1:
$ dism util$lda1:
$ mou/for util$lda1:
$ dump/blo=(c:2) util$lda1: ! note that lbn 0 still has ITRC01, but lbn 2 has KETAN
$ dism util$lda1:
$ init util$lda1: itrc01/gpt
$ mou/for util$lda1:
$ dump/blo=(c:2) util$lda1: ! note that lbn 2 is no longer a homeblock, it is EFI related stuff
$ dism util$lda1:
$ mou/ov=id util$lda1:

Jon

[Shriniketan Bhagwat]

Hi,

As I remember, the GPT structures conflict with the traditional block locations of ODS structures including the bootblock, the ODS primary homeblock, and with the index file. Accordingly, the homeblock has been relocated using the existing homeblock search algorithm, and all ODS homeblocks are now effectively secondary homeblocks, and the index file has been relocated. The GPT structure requires data structures which occupy the first 34 blocks of the disk rounded up to the cluster factor, and the last 33 blocks of the disk (also) rounded up. GPT basically maps to Protective Master Boot Record, Partition Table Header, and several Partition Descriptors. The Partition Descriptors are an array which provides the starting and ending disk block values for the partition, its name, and a GUID. Hence with GPT, the LBN2 is not the homeblock.

Regards,
Ketan

[Jon Pinkley]

I keep getting off by one errors because LBNs are zero based, not one based.

LBN 1 is what used to be the primary homeblock, but with GPT is not. I keep saying LBN 2 when I mean "second block" (or LBN 1).

Regardless, the first block on the disk (LBN 0) is what was formerly called the Boot Block, and it does not contain the label used for the mount checks. It may contain text that has the label, but that is just a comment.

The label is stored at offset HM2$T_VOLNAME in the homeblock (and should be updated in all copies of the homeblock when the set volume/label command is given). There can be many more than 2 copies (it depends on the cluster factor on the disk).

What appears to be cause of the behavior reported by Ken, is that mount/foreign is not as strict with its checks as the normal mount code. There are many fields that "must be nonzero for a valid home block", and mount/foreign evidently is not making these checks, or it would not be fooled by filling LBN 1 with 512 bytes of 0x00. That was the way I reproduced the problem condition. That probably is not the LBN involved in Ken's case, and perhaps it isn't even a block full of zeros, but something is making mount/foreign behave differently than normal mount does.

Jon

[Ken Randell]

Thanks so far for all of the clues/suggestions/answers.

I have not been able to reconstruct the exact scenario that got this disk in this shape.

Attached is the output of the LD TRACE suggested by Mr. Pinkley above. If I am reading it correctly, block 1 is being read for both mount/over=id and mount/foreign (?)

[Jon Pinkley]

Ken,

I am in the middle of work right now, but a quick glance makes me suspect that mount/foreign is misinterpreting LBN 1 as a valid homeblock (since that's all it looks at).

08:55:41.81 00.00 000B684E 0 0 NORMAL PACKACK|INHERLOG
08:55:41.81 00.00 000B684E 1 512 NORMAL READPBLK
08:55:41.81 00.00 000B684E 1 512 NORMAL READPBLK
08:55:41.81 00.00 000B684E 1 512 NORMAL READPBLK
08:55:41.81 00.00 000B684E 1 512 NORMAL READPBLK
08:55:47.57 00.00 000B684E 0 0 NORMAL UNLOAD|CLSEREXCP

Can you do the following?

$ set proc/priv=log ! or /priv=all
$ dump /block=(s:1,c:1) $1$dkb0: ! dump LBN 1

I expect to see all zeros.

If you look at the blocks being read by mount/over=id, you will see that mount keeps searching (in a specific sequence) for the home block. I would guess that it found it at LBN 15427243 (and the SCB at 15422416)

You can also do the following:

$ dump/header/block=c:0 dkb0:[000000]indexf.sys

and look at the first few retrieval pointers.

Also to see where the SCB is:

$ dump/header/block=c:0 dkb0:[000000]bitmap.sys

and look at first retrieval pointer.

Jon

[Ken Randell]

Information as requested...

logical block dump as:

dump /block=(s:1,c:1) dkb0:

shows all zeroes.

retrieval pointers for indexf.sys

Map area
Retrieval pointers
Count: 16 LBN: 48
Count: 16 LBN: 1024
Count: 16 LBN: 2064
Count: 16 LBN: 15558336
Count: 131536 LBN: 15426800

[Jon Pinkley]

Ken,

From the retrieval pointers, it appears I was incorrect in my prediction about where the homeblock used by mount/over=id was found. I now think it was LBN 1034. I also think the cluster factor on the disk is 16.

Before yesterday, I wouldn't have expected that mount/for would have been fooled into thinking a block full of zeros was a valid homeblock, but that appears to be what is happening. That is especially bad because a disk initialized with /erase will have many zero filled blocks. It just so happens that the checksums for a zero filled block are also zero, so the homeblock checksums "pass". There are many other checks that should be in play, but evidently are not.

You can probably work around the problem by writing something other than all zeros to LBN 1 (this could even be done with DCL). However, mount /for may then be confused by another zero filled block in its search for a homeblock, so it may be an iterative process. The most robust way to avoid the problem would be to init/nogpt (in my opinion, but I don't have an IA64, so perhaps that isn't a good idea. Hoff would know a lot more about it, since he was involved with the design for ODS/GPT coexistence.

More later...

Jon