Non-HP disks can prompt risks, HP reports

Reply to SCSI article questions use of non-HP devices on HP 3000s

By Jim Hawkins
HP

In the April 2003 edition of The 3000 NewsWire, John Burke wrote an article entitled “SCSI is SCSI.” In that article the author advocates that for SCSI peripherals, especially disks, HP e3000 owners should consider so called “industry standard,” non-HP devices, as a viable alternative for data storage. Although Mr. Burke has provided a lot of valuable information, I respectfully submit that his article does not fully address the risks involved in such a course of action. The base risks are primarily influenced by two factors:

1. The extent to which SCSI devices are compliant with the SCSI standard.

2. Requirements for HP Servers and the HP e3000 are not entirely “Industry Standard.”

In the following, I will address both of these subjects and present the case for only purchasing HP-certified peripherals.

The fact that the SCSI standard is well known does not guarantee that all devices will interact well or behave exactly as per the standard. “SCSI” is actually a set of standards that define physical, electrical and logical protocols for various classes of devices. (See www.t10.org for current SCSI standards information.)

As with any standard, some incompatibilities result from differing interpretations in areas where the standard may not be exact. This is analogous to the situation with “UN*X” software compatibility (HP-UX, Solaris, AIX, Linux flavors, etc.); just because someone writes a package using “Industry Standard Un*X interfaces” doesn’t mean it will work on every other system.

Another source of incompatibilities is the emphasis on certain features and behaviors over others due to market forces. In the SCSI peripheral market “Industry Standard” is really defined as “works on a PC.” Unfortunately, the requirements for single user PCs are not always in alignment with those of multi-user servers.

Mr. Burke is correct that HP sells disk mechanisms that are manufactured by highly reputable “name brand” companies. He is also correct in that these same mechanisms are often available on the open market. What he fails to correctly address is that the device’s firmware may not be the same. It turns out that the device firmware is critical to ensuring correct behavior of SCSI devices.

Before HP receives a device from a manufacturer we provide to them a “supplementary” HP Parallel SCSI Device Specification. (This document is only available to vendors supplying product to HP; so please don’t request this document.) This specification clearly states which of the myriad SCSI features HP Server systems really, truly depend upon.

HP also maintains a large staff whose entire job it is to ensure that peripherals meet our specifications. With many peripherals, we do find the need to ask the manufacturer to make more than “cosmetic” changes to the device firmware to meet our needs.

Two quotes from the HP Supplementary specification:

• “In case of a difference between the manufacturer’s specifications and those outlined in this document the latter shall take precedence. Those features or requirements that are indicated as mandatory shall be considered mandatory regardless of whether or not the ANSI SCSI specification indicates that feature or requirement is optional.”

• “Each of the fields referred to in this section shall be changeable and savable. In addition, the appropriate functionality associated with each field shall be implemented and operational.”

So, not only does HP “ask” for features and behaviors which may NOT be part of the standard, there is also the implication that HP has found that devices constructed to “Industry Standards” may not correctly implement the functionality that HP e3000 customers rely upon for the high-performance, multi-user servers. What kind of things does the HP specification include? Here is a sample of some of the subjects addressed:

• Parallel SCSI bus timing

• Power-on and Reset Behavior

• Contingent Allegiance

• Command aging

• Initiator Address

• Device Defaults (including Mode pages)

• Minimum command set (including diagnostic behavior)

Based upon my personal knowledge, many of these items are explicitly listed because at least one manufacturer at one time has not complied with HP’s specification. I will state further that in the last few years I have seen several data integrity problems found and corrected during our testing process from devices which purported to have adhered to our standard but did not actually do so.

In one case a feature was, in good faith, implemented incorrectly. Testing with “Industry Standard” (non-HP e3000) workloads did not uncover the defect. In another case, it appears that engineering constraints caused features to NOT be implemented. This decision was supported using “Industry Standard” (non-HP e3000) workloads as evidence why the feature wasn’t critical.

In each of these cases the device violated the SCSI Standard Specification as well as the HP Supplementary Specification. The devices were not from “new” or “fringe” suppliers and the devices did not appear to have a problem until HP e3000 certification tests were run.

In summary, regarding Mr. Burke’s comment, “There is nothing magical about HP-branded peripherals,” I would agree that magic has nothing to do with it. Rather, HP has invested a great deal of energy and resources into ensuring that peripherals meet HP’s standards in features and reliability by thoroughly reviewing, testing and certifying peripherals before they are allowed to carry the HP brand. The question is, are you willing to entrust your data on peripherals that have not been tested to HP’s and to the HP e3000’s standards?

Jim Hawkins is the Lead I/O Engineer in the HP MPE/iX R&D lab and has worked for HP for over 17 years in both the R&D lab and in the HP support organization.