[Info-vax] Volume shadowing and current SCSI standards ?

[chris]

On 04/29/22 17:04, Stephen Hoffman wrote:
> On 2022-04-29 12:12:07 +0000, Simon Clubley said:
>
>> On 2022-04-28, Matthew R. Wilson <mwilson at mattwilson.org> wrote:
>>>
>>> Interesting. The wording in the Volume Shadowing Guide seem to imply
>>> that VMS itself would work with devices that don't support READ/WRITE
>>> LONG, but you shouldn't use them with Volume Shadowing.
>>>
>>
>> [snip]
>>
>>>
>>> The READ LONG and WRITE LONG commands have been removed from the
>>> latest SCSI standard. I wonder if that's why VMS refused to try to
>>> work with my target when it was reporting that it was a version SPC-5
>>> implementation... VMS may know the READ/WRITE LONG commands are no
>>> longer in the standard and so rejects the new version. (Or it may
>>> have no special knowledge of SPC-5 and later at all, and just plays
>>> it safe and refuses it because it only knows about SPC-4 and below.)
>>>
>>
>> Interesting, because that has serious implications for using VMS with
>> modern hardware, especially on x86-64, if true.
>>
>> If this statement is correct, does this mean that VMS volume shadowing
>> will no longer work with devices which use only the latest SCSI
>> standard ?
>>
>> If so, I wonder how VSI plan to address this ?
>
> READ LONG (3eh) is deprecated in current standards, while WRITE LONG
> (3fh) is mostly-deprecated. The write-uncorrectable feature is still
> part of SBC-5. Otherwise, not so much.
>
> Host-based RAID-1 HBVS also works with devices that don't support READ
> LONG and WRITE LONG, including ~working with IDE/ATA devices going way
> back. The volume gets kicked of the club, err, volume set, on read error.
>
> SSDs revector everything on write for wear leveling and performance
> purposes too, which means READ LONG and WRITE LONG aren't all that
> useful; we're increasingly not on HDDs.
>
> How will VSI deal? Controller-based (whether in-board and out-board)
> RAID support, and limiting support to devices with firmware compatible
> with host-based RAID-1 HBVS, and using the one-and-done capabilities and
> device EDC, same as it has been.
>
> Storage compatibility has been a quagmire for decades (and probably
> longer), and bugs and mis-implemented features and custom firmware and
> surprise status returns are all common.
>
> The storage compatibility lists, and related testing, and supported
> configuration documentation and management, are no small effort.
>
> Past configuration support docs, VSI has a whole pile of I/O work
> awaiting here too, whether this for host-based RAID-1 HBVS, or adding
> support for NVMe or NVMe-oF storage, better support for monitoring SSD
> DWPD status and errors, maybe adding support for EXTENDED COPY (83h)
> where available, or file system supporting volumes larger than 2 TiB
> and/or FUSE and/or pluggable file systems, or otherwise. There are
> easily decades of work awaiting; as much as VSI might want or can add.
>
> What'd also be interesting (for VSI) is some current error rate data
> around OpenVMS itself. I've seen some published reports of as much as 3
> to 6 hard errors arising per terabyte, for generic HDD storage. (That
> seems high, but we've also all met junk-grade storage.) Unfortunately,
> OpenVMS is somewhat lacking in (opt-in) telemetry for feature use and
> data collection purposes, so VSI can't (easily) know.
>
> Older error info:
> https://www.microsoft.com/en-us/research/wp-content/uploads/2005/12/tr-2005-166.pdf
>
>
> Newer error info:
> http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/23105-fast16-papers-schroeder.pdf
>
>

May be irrelevant, but HP Smartarray controllers, have built in
firmware to define various raid levels and are trivial to setup
from bios. Not only that, but a failed raid member can typically be
physically replaced with no host intervention at all. The Smartarray
firmware just rebuilds the set in background. Not all allow
transparent access to individual drives, but must be part of a set, even 
a single drive, to be seen by the host.

Have use those controllers for years and they are pretty bulletproof,
but not sure how they would work with vms...

Chris