Missing '/foreign' labels on image backups

[Ken Randell]

VMS on IA64, 8.2-1, 8.3, 8.3-1H1

Upon rare occasion I will have a condition where a disk seems to lose its 'mounted/foreign' label. By this I mean, I can mount the disk (physical or logical unit as part of a raid set) with the usual mount/over=id commands, but a mount/foreign will return a 'null' label as if the disk were empty. Otherwise, the drive looks perfectly normal with no missing information. ANA/DISK doesn't show any problems.

If I take an image backup of disk in this condition and restore it to another drive, the 'null' label moves with it.

All drives were originally created with the usual INIT command and a non-image restore (i.e., I restore a directory tree to a disk).

I have never seen this on ALPHA; I am using ODS-5 drives in all cases. As mentioned, I have seen this on 18gb and 72gb drives as well as logical units carved up from a p400 raid controller.

The only fix I know of is to INIT the disk again, and do a non-image restore of the drive using various backup qualifiers such as /owner=original, etc. SET VOLUME/LABEL=xxxx doesn't fix this.

The only reason this matters is that there's a command procedure in play at boot time that wants to check the volume label to make sure the right drive is in the right place. I realize I could remove this check, but it still seems kind of bizarre that this is happening...

ENGZZD $ mount/over=id dkb0:
%MOUNT-I-MOUNTED, DSPS mounted on _$1$DKB0: (ENGZZD)
ENGZZD $ dism dkb0:
ENGZZD $ mount/for dkb0:
%MOUNT-I-MOUNTED, mounted on _$1$DKB0: (ENGZZD)
ENGZZD $ dism dkb0
ENGZZD $ mount/over=id dkb0:
%MOUNT-I-MOUNTED, DSPS mounted on _$1$DKB0: (ENGZZD)
ENGZZD $ set volume/label=dsps dkb0:
ENGZZD $ dism dkb0
ENGZZD $ mount/for dkb0:
%MOUNT-I-MOUNTED, mounted on _$1$DKB0: (ENGZZD)
ENGZZD $ mount/over=id dkb0:
%MOUNT-I-MOUNTED, DSPS mounted on _$1$DKB0: (ENGZZD)
ENGZZD $ ana/disk dkb0:
Analyze/Disk_Structure for _$1$DKB0: started on 18-NOV-2010 11:10:31.89

%ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS
-SYSTEM-W-NOSUCHFILE, no such file
ENGZZD $ dump /block=count=1 dkb0:


Dump of device DKB0: on 18-NOV-2010 11:17:26.64

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

03039401 001E65C0 11C00200 15C600A0 ..F...@.@e...... 000000
8BDFFF76 905F0000 000501FB 000609F7 w...{....._.v._. 000010
20202020 20205350 53440087 80FDFF74 t.}...DSPS 000020
73206120 746F6E20 73692020 20202020 is not a s 000030
0000000A 0A0D6B73 6964206D 65747379 ystem disk...... 000040
00000000 00000000 00000000 00000000 ................ 000050
00000000 00000000 00000000 00000000 ................ 000060

etc.

Any ideas/hints/suggestions gratefully accepted. Thanks.

[John Gillings]

Ken,

What does DUMP show when a disk is in the odd state? In particular, the field that normally contains the label.

Perhaps a reasonable workaround in your check would be to accept a null label, or look elsewhere on the disk.

For example, there are lots of alternate home blocks in the first few clusters of INDEXF.SYS - you should be able to find numerous copies of the volume label.

See DUMP/BLOCK=COUNT:10 dev:[000000]INDEXF.SYS

Surely they can't all have gone bad? Even if the device is mounted /FOREIGN, finding INDEXF.SYS isn't too difficult.

[John Gillings]

Oh, almost forgot...

When/if you can get some documented information about the (mis)state of the disk, and the sequence of events leading up to it, please log a case with HP. They can't fix what they don't know about (there are only a few HP engineers who read ITRC - and responding to issues raised here is not in anyone's metrics).

[Robert Gezelter]

Ken,

A DUMP/ASCII/HEX of the primary and spare copies of the home block would be helpful.

- Bob Gezelter, http://www.rlgsc.com

[John McL]

I wouldn't expect a volume label when mounting a disk /FOREIGN.

From the DCL manual, under the MOUNT command...

"The volume-label parameter [2nd parameter] is not required when you mount a volume with the /FOREIGN or /NOLABEL qualifier or when you specify /OVERRIDE=IDENTIFICATION."

(Note that it doesn't say why it's not required.)

and later ...

"/FOREIGN
Indicates that the volume is not in the standard format used by the OpenVMS
operating system. Use the /FOREIGN qualifier when a magnetic tape volume is not in the standard ANSI format, or when a disk volume is not in Files-11 format. If you mount a volume with the /FOREIGN qualifier, the program you use to read the volume must be able to process the labels on the volume, if any."

(i.e. volume labels are not processed)

MOUNT/FOREIGN is used with BACKUP/IMAGE because you want the volume label to copied from the disk that you are backing up.

The fact that when you do a MOUNT/OVER=IDENT and the disk appears with the correct volume label looks to me as if it was saved on the disk but not accessed with the MOUNT/FOREIGN command.

Now I expect that someone will tell me that I'm wrong ...

[John Gillings]

re: John McL

>Now I expect that someone will tell me
>that I'm wrong ...

What you say is correct - you are not required to specify a volume label when mounting a volume /FOREIGN, or with /OVERRIDE=ID.

However, when you mount such a volume, I would expect the system to display the volume label it finds - see the example %MOUNT-I-MOUNTED messages in Ken's post. Indeed, mounting /FOREIGN is one way to determine an unknown volume label (which is what I believe Ken is depending on)

[Jon Pinkley]

Ken,

One thing I would try is to use

$ set volume/label=DSPSNEW $1$DKB0:
$ set volume/label=DSPS $1$DKB0:

It is possible that there is some "optimization" being done and the volume label isn't rewritten if it is the same as the present label. This seems to be the case on Alpha OpenVMS 8.3 with an ODS2 disk, it reads the home block but does not update it if the previous label was the same.

This still doesn't address the underlying problem, but it may be a work around that is less work than restoring a disk (if it works).

If you have LDDRIVER loaded, it would be interesting to see what LBNs are being accessed when the disk is mounted.. If you are going to try this, do it before attempting to change the volume label. This can be done by using the

$ set proc/priv=all
$ LD connect /replace $1$DKB0: LDA100:
$ LD trace LDA100:
$ mou/ov=id LDA100:
$ dism LDA100:
$ mou/for LDA100:
$ dism LDA100:
$ LD show/trace LDA100:

and see what blocks are being read.

Then to revert to normal access:

$ ! assumes already dismounted
$ LD notrace LDA100:
$ LD disconnect LDA100:
$ mou/ov=id $1$DKB0:

Jon

[Jon Pinkley]

Ken,

I can reproduce on an Alpha with a disk initialized /GPT (and use of DISKBLOCK). Sorry, the following is a running commentary in chronological order, and I didn't discover the reproducer until near the end...

I don't have an IA64, but I am wondering if this behavior could be related to /GPT (which is the default on IA64, but not on other architectures). If you have a [000000]GPT.SYS file, your disks are initialized with the GPT overlays, and these are in the blocks normally occupied by the boot and primary home blocks.

With /GPT, there is no longer a primary homeblock. Perhaps the mount/foreign code doesn't use the same checks for the home block as the normal mount code does. I don't know what checks are made by the mount/foreign code for valid home blocks, but it may be finding what it considers to be a home block that really isn't one, and then the volume label wouldn't be correct. For example, if the mount/foreign code only check for valid checksums, a block of 0x00 bytes would pass the test. Perhaps the mount/foreign code is not using the same search sequence for home blocks as the normal mount code, or perhaps its checks are not as strict.

Here is a good way to get a formatted dump of the HOMEBLOCK of the disk.

ftp://ftp.hp.com/pub/openvms/freeware/diskblock/diskblock.zip

This is DISKBLOCK 6.2, and the kit will install on IA64.

Whoever created the zip file must not have preserved the vms file attributes, because the contents need to be
repaired.

You will need to do the following to "reconstitue" the vmsintal kit.

$ unzip diskblock
$ backup/list/repair diskblock062.a
$ backup/list/repair diskblock062.b
$ backup/list/repair diskblock062.c
$ backup/list/repair diskblock062.d
$ backup/list/repair diskblock062.e

Install diskblock, then do the following:

$ mount/for $1$dkb0:
$ mcr diskblock
DISKBLOCK> select $1$dkb0:
DISKBLOCK> read 1 ! primary homeblock (but will be bogus with /GPT)
DISKBLOCK> dump/home

See if the checksum if valid

DISKBLOCK> read 2 ! or what the Alternate Home LBN:
DISKBLOCK> dump/home

Well, it isn't too hard to reproduce the problem on an Alpha (as long as we are able to use DISKBLOCK to write to the disk).

My guess is that the EFI console is either writing to some block in the GPT and then mou/for is seeing this as a home block, or there may be left overs as described in Hoff's writup on OpenVMS Tips: EFI GPT Structures on ODS-2 and ODS-5 Disks

http://labs.hoffmanlabs.com/node/112

Here's what I did to reproduce the "effect" of having mou/ov find a label that mou/for does not. Note that this can be a serious problem if you are using shadowing, because the normal bladeguards in the SCB are bypassed (because the SCB can't be found if a valid homeblock is not found). For example if the disk is a member of a shadow set, and then the shadow set is dismounted or a member is dismounted, normally VMS will writelock this device when it is mounted without /shadow or /over=shadow. But that is not the case if a valid homeblock is not found.

$ init lda100: itrc01 /sys /own=[1,1] /cluster=1 /limit=10000 /gpt

At this point mount/for will find the label ITRC01.

However if we overwrite LBN 2 with all zeros (using DISKBLOCK), the volume will still mount correctly with mount/over=id, but will mount with no label displayed when mounted with mount/for. Also, if this volume is converted to a shadowset, it will not be protected against accidental write by mou/for.

See attachment for more details.

Jon

[Jon Pinkley]

Ken,

By the way, changing the volume label won't help the problem, since the set volume/label updates the valid homeblocks, not the block that is being interpreted as a homeblock by mount/foreign.

Two possible work arounds that I can think of. If /GPT isn't needed the next time you got through the init, restore, do an init/nogpt.

The other is to try to determine what block is being interpreted incorrectly, and try to modify the block so the checksums are incorrect. But this may break something if the EFI is really using the block. The tool to modify the block is DISKBLOCK.

The real fix is for HP to make mount /foreign use the same search/checks for homeblocks as the normal mount code does, and issue a patch. Unfortunately they will probably only supply that patch to people with valid software contracts, even though it is not an enhancement, only a correct implementation of functionality.

Jon

[Jon Pinkley]

Ken,

I just tried the following, but it does not work. So a non-image restore appears to be the only supported way to "cleanup"

$! following does not work!
$ init ... /nogpt
$ mou/for
$ backup/image/noinit

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

And you can't delete GPT.SYS while the disk is mounted files-11. It may be possible to use DISKBLOCK to delete the GPT.SYS file, but it would be much easier to just use a non-image restore like you discovered.

Jon