[Info-vax] Alpha SCSI disks won't mount on integrity

[Stephen Hoffman]

On 2021-12-22 15:33:21 +0000, hb said:

> On 12/22/21 3:54 AM, Stephen Hoffman wrote:
>> INIT /ERASE /GPT /SYSTEM /STRUCT=5 [...] the disks on OpenVMS Alpha 
>> (with adequate max files and headers set, as the INIT defaults are 
>> ~always bad), re-populate the disk contents, and try the transfer again.
> 
> The OP said, the disk is "offline". Maybe there is some magic in this 
> init command but I would not expect that anything on the disk will 
> change the status, so it will be "online".

OP also stated they were able to access those volumes /FOREIGN. Which 
would not be expected were this a SCSI controller-level issue and not a 
higher-level issue, such as a MOUNT-level issue.

But without commands used and error codes shown, who knows?

> The OP said, they want to move data. /GPT is not required for data 
> disks and I don't see any benefit having a file in the MFD which 
> occupies LBN 1, the traditional home of the home block. It doesn't 
> hurt, either, just a small waste of disk space and mount time.

/GPT use an entirely negligible about of storage, and it is a technique 
that will prevent a down-revision Integrity console from stomping on 
ODS-2 and ODS-5 storage as has been its wont, if EFI happened to find a 
stale GPT around.

Newer EFI firmware allegedly warns before stomping, but I've long been 
skeptical of depending on that.

And use of /ERASE gets HDD storage to a known state, clears out any 
existing rubbish on the volume, and also provides a simplistic but 
fairly effective test of the viability of the HDD storage.

Use of /ERASE and enabling highwater marketing can have benefits around 
using SSD storage on some storage hardware too, but this is HDD and not 
SSD, and potential SSD optimizations are are fodder for another time.

There were various "fun" bugs when transporting disks, and when 
receiving supposedly-new HDD disks that already had GPTs present from 
testing or whatever. The ugly hack that allows ODS-2 and ODS-5 to 
(badly) coexistence with GPT did trip over some interesting cases, per 
the developer that designed and implemented the hack. This'd also be 
vastly easier with actual GPT partitioning support in OpenVMS, and 
which would also provide a differently-hacked way to use ODS-2 and 
ODS-5 volumes on HDDs and SSDs larger than 2 TiB at the cost of 
negligible quadword arithmetic for each I/O, but that too is fodder for 
another time.

OpenVMS arguably retired the "traditional location" of the homeblock at 
V8.0 too, and that placement and the alternates have all been 
acceptable for a while, once a few details such as some latent math 
bugs were worked out with "unexpected" HDD and SSD storage volume sizes.


-- 
Pure Personal Opinion | HoffmanLabs LLC