Solid-state disks on rx2660 and OpenVMS v8.3-1H1

[Max Bruno Jarvis]

Does anyone have any experience with solid-state SATA disks on rx2660 with v8.3-1H1?

In fact, has anyone had success with ANY sort of solid-state disk and rx2660?

I'm trying to use a SATA SSD (solid-state-disk) in place of a SAS rotating disk, in one of the 8 slots in an rx2660. SATA is allegedly compatible with SAS, but it doesn't work properly. SHO DEV looks sensible, i.e. it reports the right number of blocks etc, but any attempt to MOUNT it gets error mount-f-abort, and any attempt to INITIALIZE it gets init-f-abort. It does seem able to receive an image copy (BACKUP /IMA) and has a try at booting, but gets stuck in endless Mount Verification. I tried to look at the error log for a failed MOU attempt, but ELV says it can't translate from bits to text.

BTW, our requirement is not for better speed than rotating disks, but for better ability to withstand shocks.

[Ian Miller.]

I can't see any solid-state SATA disks listed as qualified with the rx2660.

Which disk it you are trying?

[Hoff]

No, I haven't tried an SSD in this configuration, but I have been involved with a whole pile of hardware-level "fun" around getting these "compatible" widgets to work.

Devices are referred to as "compatible" because they're inherently "different". If the devices were "not different", then they would be referred to as "identical" and not as "compatible".

As for the hardware, SAS is an upgrade from and a two-connection wiring scheme and superset of SATA, and a SAS controller can drive a one-connection SATA disk. A SATA controller cannot drive a SAS disk.

Some of these boxes had programmable controllers, and you'd need to ensure the RAID and JBOD settings are sorted out, and that the controller is happy with the widget.

The question here is around what commands and responses are implemented within the device, and that can differ. Wildly. Work for a while at the command level and you'll be amazed that this stuff even works, much less the software can manage the differences among various "compatible" devices.

You can check the error log, but this smells like there's a command-level difference or a status difference with bringing the device fully on-line. Check the error logs.

Unless you're prepared to rework the host device drivers here (the PK and DK pieces) or rework the device firmware, your choices are limited to convincing somebody (usually HP) to work on these, or to try a different device.

HP does offer SSDs for this StorageWorks form factor, but I've not checked SPOCK for support with this hardware and with VMS, and I expect Ian likely has.

http://h18004.www1.hp.com/products/quickspecs/13415_div/13415_div.html

What usually happens with storage device qualification is a test sample of the hardware is brought in-house at the vendor, and low-level command and status diagnostics tools are run against the device; basically, the delta between what's "compatible" and works and what's "compatible" and doesn't work is determined, and then in descending order of relative desirability and rough order of increasing effort, the device drivers are tweaked, the device firmware is tweaked, the drivers are overhauled, or the device or its firmware is overhauled.

Occasionally, the hardware controllers or the controller firmware can be incompatible, but that's comparatively rare.

For the low-level console configuration, EFI can sometimes get tangled and confused and fall over here, too.

And AFAIK, the VMS SCSI drivers has no support for the SCSI TRIM command, which some of the SSDs can expect.

Another potential option here is adding driver or support for PCIe SSD. Exactly what is required here depends on what I/O interface the PCIe widget presents to the host, and how "compatible" that might be with existing and supported I/O interfaces.

All together, you're going to be working directly with HP here, or spending rather more time with a bus analyzer and the storage vendor sorting out the differences through your own qualification process, or possibly both.

(Reposting this as ITRC is being ITRC again today.)

[Max Bruno Jarvis]

I suspect maybe there are no SATA SSDs 'qualified' for rx2660, but I'm told that the SAS spec says SAS is backward compatible with SATA, i.e. you can use a SATA disk on a SAS interface (but not the other way round). The rotating disks in the rx2660 are SAS, so on the face of it, it should work. The SSD is a Memoright model MRS020A032GTS25C (32GB, SLC-flash). It fits in the same disk caddy as the rotating disk, with the same pins to connect it.

Where did you find the list of disks 'qualified' for the rx2660? I'd like a look at that list...

[Hoff]

HP SPOCK:

http://h20272.www2.hp.com/

"SPOCK is the primary portal used to obtain detailed information about supported HP StorageWorks product configurations."

[Hoff]

ps:

>I suspect maybe there are no SATA SSDs 'qualified' for rx2660, but I'm told that the SAS spec says SAS is backward compatible with SATA, i.e. you can use a SATA disk on a SAS interface (but not the other way round).

A SAS HBA can drive SAS and SATA devices, where a SATA HBA can only drive SATA devices. The SATA wiring and connectors are a proper subset of SAS wiring, as well.

>The rotating disks in the rx2660 are SAS, so on the face of it, it should work.

That one SAS device worked does not imply that any other SAS device will work.

These are complex interfaces, and the product designs can and do vary widely, across product lines and sometimes even within the same vendor's product lines, and occasionally from one firmware revision of a specific product to the next.

"Compatible" is the "marketing definition" of the problem here, and there's some slop in the definition.

"Qualified" is the "engineering definition", and there's far less slop in the definition.

[Max Bruno Jarvis]

Thanks for replies. It appears my SATA SSD works in a standard PC which expects a SATA disk, but not on an rx2660 and not on a Proliant server, both of which expect SAS disks. Can't say much more than that, I'm afraid.