[Info-vax] 3rd party SATA SSD usage on RX2660+P400 in a production environment?

[Terry Kennedy]

On Monday, July 1, 2019 at 5:11:23 PM UTC-4, Hans Vlems wrote:
> Follow up on my own post :( 
> I swapped an HP 72 GB disk with the 850 EVO. The contents were copied by a BACKUP/IMAGE command. 
> Shut down (power off) the rx3600, swapped the SSD and booted the system. Mount command failed with an %MNT-F - Abort message. 
> It may work, but not reliable. 

I think this is the important part:

> sho dev dka300/full     ! which still identifies itself as an HP drive

As long as the system wasn't shut down, some part still thought it was talking to the original drive.

Most of VMS except the drivers is pretty tolerant of a wide variety of peripherals. I've been able to pass through quite a few oddball disk devices to an Alpha VMS instance running on an emulator (AlphaVM). The trick is that the emulator maps the real hardware's command set into SCSI, so that's what VMS sees.

Back to the particular case of the Samsung SSD - something along the way is likely using SAT (SCSI/ATA Translation) to map the SSD into something that looks like a SAS drive. It could be the controller, a SAS expander (found on the backplane), etc. The quality of SAT implementations varies a good deal, and interactions with expanders can be particularly problematic.

I'd use a SAS SSD rather than a SATA one to avoid some (most) of these issues - my emulated Alpha is currently using a volume consisting of:

<SanDisk LT0400MO D416>            at scbus0 target 0 lun 0 (pass0)
<SanDisk LT0400MO D416>            at scbus0 target 1 lun 0 (pass1)
<SanDisk LT0400MO D416>            at scbus0 target 2 lun 0 (pass2)
<SanDisk LT0400MO D416>            at scbus0 target 3 lun 0 (pass3)
<DP BACKPLANE 1.07>                at scbus0 target 32 lun 0 (ses0,pass4)