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

[Stephen Hoffman]

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 




-- 
Pure Personal Opinion | HoffmanLabs LLC