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

[Rich Jordan]

On Wednesday, December 22, 2021 at 1:46:18 PM UTC-6, Stephen Hoffman wrote:
> 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

Hoff, replied to Rob also with command and output, but didn't get the errorlog info before the RX got commandeered by our dev team, I can get on it again next week.  It is booted off a different system disk for dev work...

Did as you suggested, and the drive mounted (/system),  but only once on the RX.  Got bus and drive errors trying to write to the disk, but a backup to saveset did complete.  I then dismounted the drive, tried to remount it and got the offline response.  Mounted foreign again, and that worked, and dumping a lot of blocks generated no errors.  I didn't get a chance to pull event log entries before losing access to the RX.

Command used and response:

$ MOUNT/SYSTEM ALTI64$DKB500: TALPHASYS
%MOUNT-I-OPRQST, medium is offline
%MOUNT-I-OPRQST, Please mount volume TALPHASYS in device _ALTI64$DKB500

The operator request I didn't log but it was the standard please mount volume.  Replying to it didn't work, it generated a new identical request

Sorry for the disjointed responses.  Work is supposed to slow down and let us catch up and clean up, but instead we're getting hammered.

Rich