[Info-vax] USB disk enclosures

[Stephen Hoffman]

On 2016-10-25 19:38:25 +0000, Hans Vlems said:

> My DS10 at home runs axp/vms v8.4.
> It has a chinese USB interface that is recognized by VMS. Memory sticks 
> of various sizes work well and are recognized with their specific DNA 
> device number.
> Enter two 2.5" SATA disks, 80 GB and 120 GB respectively. I bought two 
> identical disk enclusures put the disks in and did an init/system on 
> the 80G drive on the DS10. Mounting worked well and I copied 40GB of 
> disk images to it.
> Dismounted the DNA device. Disconnected the disk and replaced it with 
> the 120G disk enclosure.
> It got the same DNA device number. Init/system resulted in an error 
> message that the number of blocks was different from the previous time 
> the device was mounted. A backup to it failed and the DNA device was in 
> mount verification state.

I'm assuming that this volume was not mounted in parallel.  Parallel 
MOUNTs can happen both on a single system, and in a cluster, and will 
keep the volume data around pending the last DISMOUNT and probably as 
far as the last channel deassign.   It's also remotely possible that 
the USB enclosure is caching something here, too.  Did that get 
power-cycled?   If the volume was completely dismounted everywhere, and 
if the USB enclosure was power-cycled, then this reeks of a bug in the 
USB support.   I'd expect a IO$_PACKACK to be sent as part of the MOUNT 
processing, and to detect and resize the reported capacity of the 
volume.   The PACKACK is sent into the I/O stack and causes the device 
driver to try to identify and size the volume loaded in the drive.  
SCSI, MSCP and other sorts of drives all handle PACKACK for the express 
purpose of determining the size of the volume.   CD and DVD media is 
particularly prone to volume size changes, too.   The device serial 
numbers are very far from universally implemented on USB devices.

Try the sequence again, using some local source code 
http://labs.hoffmanlabs.com/node/755  to toss a $qio IO$_PACKACK at the 
device, then see if the volume data reported by $getdvi changes.   The 
PACKACK should happen automatically, but performing the $qio sequence 
manually will show whether the reported data changes or not.

If OpenVMS is somehow caching the volume size in the device data across 
a re-powered enclosure disconnect-connect — that's really ugly — then 
changing that saved data is probably the only path, if the USB stack is 
not detecting that automatically.    Hot-patching this is pretty ugly, 
too.   That pending some USB driver fix from VSI or HPE.



-- 
Pure Personal Opinion | HoffmanLabs LLC