On 2022-04-28, Matthew R. Wilson <mwilson@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 ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Friday, April 29, 2022 at 8:12:10 AM UTC-4, Simon Clubley wrote:
> On 2022-04-28, Matthew R. Wilson <mwi...@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 ?
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

The current HBS product requires the use of the READ/WRITE LONG commands so you are correct HBS won't work with devices that don't support it. Many customers now use SAN devices and the "shadowing" takes place there rather than being host based which avoids the issue. I have seen the shift with many of my clients to this "new" way. Yes HBS is valuable for many reasons, but there are alternatives that are increasingly being used today. While this should be addressed, I don't think it has the urgency that you incidate.

Dan

In article <t4gkmn$5fo$1@dont-email.me>, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> 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 ?

Interesting. What is affected? Alpha? X86? Both? Only VSI VMS?

Will anyone use SCSI disks on x86?

In article <68f2137f-d0e6-4921-98ee-854022f7d751n@googlegroups.com>,
abrsvc <dansabrservices@yahoo.com> writes:

> The current HBS product requires the use of the READ/WRITE LONG commands
> so you are correct HBS won't work with devices that don't support it.
> Many customers now use SAN devices and the "shadowing" takes place there
> rather than being host based which avoids the issue. I have seen the
> shift with many of my clients to this "new" way. Yes HBS is valuable
> for many reasons, but there are alternatives that are increasingly being
> used today. While this should be addressed, I don't think it has the
> urgency that you incidate.

Merely the fact that most don't expect such an essential feature to
break should be reason to address it.

SAN? Yes, can provide help if a disk fails. But what about multi-site
clusters with members with physical connections to different nodes?

And what about HBVS on hobbyist machines? :-)

On Friday, April 29, 2022 at 11:25:04 AM UTC-4, Phillip Helbig (undress to reply) wrote:
> In article <68f2137f-d0e6-4921...@googlegroups.com>,
> abrsvc <dansabr...@yahoo.com> writes:
>
> > The current HBS product requires the use of the READ/WRITE LONG commands
> > so you are correct HBS won't work with devices that don't support it.
> > Many customers now use SAN devices and the "shadowing" takes place there
> > rather than being host based which avoids the issue. I have seen the
> > shift with many of my clients to this "new" way. Yes HBS is valuable
> > for many reasons, but there are alternatives that are increasingly being
> > used today. While this should be addressed, I don't think it has the
> > urgency that you incidate.
> Merely the fact that most don't expect such an essential feature to
> break should be reason to address it.
>
> SAN? Yes, can provide help if a disk fails. But what about multi-site
> clusters with members with physical connections to different nodes?
>
> And what about HBVS on hobbyist machines? :-)

I don't think you can state that HBVS breaks as the restriction exists today and has for quite some time.

I would guess that the restriction didn't raise a lot of reports with VSI which is one reason for it not being addressed (not addressed rather than fixed).

It might be an issue for hobbyists, but lets get real, the main focus will be for paying customers.

Dan

On 4/29/22 9:25 AM, Phillip Helbig (undress to reply) wrote:
> In article <68f2137f-d0e6-4921-98ee-854022f7d751n@googlegroups.com>,
> abrsvc <dansabrservices@yahoo.com> writes:
>
>> The current HBS product requires the use of the READ/WRITE LONG commands
>> so you are correct HBS won't work with devices that don't support it.
>> Many customers now use SAN devices and the "shadowing" takes place there
>> rather than being host based which avoids the issue. I have seen the
>> shift with many of my clients to this "new" way. Yes HBS is valuable
>> for many reasons, but there are alternatives that are increasingly being
>> used today. While this should be addressed, I don't think it has the
>> urgency that you incidate.
>
> Merely the fact that most don't expect such an essential feature to
> break should be reason to address it.

Read/Write Long was marked obsolete more than a decade ago. Thus, I
would think that if it had a negative impact on any of VSI's customers,
they would have let VSI know.

>
> SAN? Yes, can provide help if a disk fails. But what about multi-site
> clusters with members with physical connections to different nodes?

Multi-site clusters are actually one of the strengths of SAN. SAN
protocols support long distances much better than the SCS protocol does.
In fact, I wonder if it would be practical (or possible) to eventually
run cluster traffic over fibre channel.

>
> And what about HBVS on hobbyist machines? :-)
>

I realize you asked this tongue-in-cheek but hobbyists tend to get most
of their equipment on the used market. The used market still has plenty
of stuff that still supports Read/Write Long.

Mark Berryman

On 2022-04-29 12:12:07 +0000, Simon Clubley said:

> On 2022-04-28, Matthew R. Wilson <mwilson@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

On Friday, April 29, 2022 at 8:23:03 AM UTC-7, Phillip Helbig (undress to reply) wrote:

(snip)

> Will anyone use SCSI disks on x86?

As well as I know, all SATA disks will also accept SCSI commands,
and many systems run them that way.

My choice would be NFS, though.

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@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

On 2022-04-29 20:06:58 +0000, gah4 said:

> On Friday, April 29, 2022 at 8:23:03 AM UTC-7, Phillip Helbig (undress
> to reply) wrote:
>
> (snip)
>
>> Will anyone use SCSI disks on x86?

The sorts of ancient and slow HDDs and parallel SCSI that you're
familiar and accustomed to? No. That written, much of the available
x86-64 storage uses SCSI commands.

> As well as I know, all SATA disks will also accept SCSI commands, and
> many systems run them that way.

SAS, ATAPI, iSCSI, iSER, SATA with SCSI translation, most USB storage,
NVMe with SCSI translation, and other such storage, and other giblets
are scuzzy, err, use SCSI commands.

ATA and SATA storage without the translation use ATA.

NVMe and NVMe-oF without the SCSI translation (and if you're not
tunneling NVMe over SCSI, wheeeee!) goes direct.

If you're booted in a guest in a hypervisor, you're probably going to
get an emulated LSI SAS controller or ilk and SCSI commands, and
increasingly also an emulated NVMe controller sans SCSI commands.

> My choice would be NFS, though.

SMB won, in the general case. On OpenVMS, OpenVMS lacks SMB client
support, and does have NFS client and server support, though both
client and server need some help.

ps:
https://www.seagate.com/files/www-content/product-content/ssd-fam/nvme-ssd/nytro-xf1440-ssd/_shared/docs/an-introduction-to-nvme-tp690-1-1605us.pdf

https://www.scsita.org/wp-content/uploads/2020/08/SAS_vs_NVMe_Interface_Smackdown-final2.pdf

https://www.snia.org/sites/default/files/news/iSCSI-Future-Cloud-Storage-Doomed-NVMe-oF.pdf

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-04-29 22:11:24 +0000, chris said:

> On 04/29/22 17:04, Stephen Hoffman wrote:
>>
>> ...Controller-based (whether in-board and out-board) RAID support...
>
> 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...

Various Compaq, HP, and HPE Smart Array controllers are supported on
OpenVMS, and have some nice features. Some is commonly used as core I/O
on some of the Integrity Itanium servers.

The Smart Array x86-64 BIOS configuration stuff is occasionally
problematic with OpenVMS on Alpha or Itanium, but it does work.

One of the more quietly useful features of the Smart Array is the
ability to migrate the storage to a different Smart Array controller by
swapping (just) the HDDs, or swapping the cables around. That's been
handy.

For controllers lacking UEFI support or HTTPS support or ilk, VSI will
either need to work with the controller vendors to create configuration
tools for OpenVMS x86-64, or boot a vendor-supported platform to
reconfigure the controller.

I'm mostly using Promise Pegasus and Synology storage in the low-end
DAS/NAS positioning else-platform, but the Smart Array gear does work
well for low-end DAS RAID storage.

--
Pure Personal Opinion | HoffmanLabs LLC

On 04/30/22 00:12, Stephen Hoffman wrote:
> On 2022-04-29 22:11:24 +0000, chris said:
>
>> On 04/29/22 17:04, Stephen Hoffman wrote:
>>>
>>> ...Controller-based (whether in-board and out-board) RAID support...
>>
>> 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...
>
> Various Compaq, HP, and HPE Smart Array controllers are supported on
> OpenVMS, and have some nice features. Some is commonly used as core I/O
> on some of the Integrity Itanium servers.
>
> The Smart Array x86-64 BIOS configuration stuff is occasionally
> problematic with OpenVMS on Alpha or Itanium, but it does work.
>
> One of the more quietly useful features of the Smart Array is the
> ability to migrate the storage to a different Smart Array controller by
> swapping (just) the HDDs, or swapping the cables around. That's been handy.

Avery useful feature. Tyical scenario might be where an older machine is
upgraded to a later machine. Older machine might have a mirrored os /
root drive, then a second mirrored pair or raid 5 set for data, both
with hot swap spares or not, Trivial to setup with Smartarray, but
assuming the os is installed on the new machine, the data disks
from the old machine just need to be moved over, power up and the
controller imports the set with no intervention. saves having to
do backup / restore and can save a lot of time.

Another interesting ability with a mirrored pair is that it's
easy to clone the set by removing one drive, plug in to another machine
and the controller on both will request a replacement drive, then
rebuild both mirrors in the background. Very useful if you need to clone
a system disk, for example.

> Thanks for the update. We were at the house Thursday and the furniture
> in the garage was cleared and floor swept out. Garden shed cleared as
> well. There are still a few items in the garage, small part, to be
> collected on Saturday, but that should be it. The cleaners arrived
> while we were there seemed to be quite thorough, but will check on
> Saturday.
>
> As for the delay, a few days either way is not an issue here and don't
> want to put any pressure on Katherine. It's stressful enough for her
> already, so please reassure her and i'm sure it will get done...
>
> Regards,
>
> Chris

lder machine

>
> For controllers lacking UEFI support or HTTPS support or ilk, VSI will
> either need to work with the controller vendors to create configuration
> tools for OpenVMS x86-64, or boot a vendor-supported platform to
> reconfigure the controller.
>
> I'm mostly using Promise Pegasus and Synology storage in the low-end
> DAS/NAS positioning else-platform, but the Smart Array gear does work
> well for low-end DAS RAID storage.
>
>