[Info-vax] The new world that VMS will be living in

[Stephen Hoffman]

On 2020-12-08 01:25:33 +0000, Mark Berryman said:

> Data loss can be protected against.  For me, the real issue is the 
> number of instances (that have been reported) of the major cloud 
> vendors saying "oops, we accidentally leaked this customer's data".  
> AWS is the vendor I've seen this happen to the most.

Ayup. Folks configuring their storage and configuring their backups and 
configuring their security, we all get in trouble here.

That's not new either, and that's not unique to hosted, and that's not 
unique to our increasingly-networked private networks and private 
hosts. Where those are actually private. Which I'm increasingly 
skeptical about.

Same risks arise locally. OpenVMS lacks full-disk encryption support, 
which means you need external hardware to secure your data. And I'd 
expect some folks reading this posting aren't yet using BACKUP 
encryption. And so on.

Same scheiße, different data locality.

> Another issue that will need to be resolved is the performance of VMS 
> backup.  I use an LTO7 tape library for backups, which has a theoretic 
> maximum transfer rate of 300MB/S.  On a DS15, with a 1GHZ cpu clock, I 
> can't get any more that 75MB/S.  On an RX2620, with a 1.6GHZ cpu clock, 
> I can't get any more than 95MB/S.  In both cases, the rate limit was 
> hit because the backup process had maxed out the CPU.

I've grumbled about OpenVMS BACKUP and its 
approaching-the-theoretical-limits design, too.

> By comparison, when I backup my Mac to the same tape drive (all systems 
> are part of a SAN) I get over 200MB/S.

Local SMB performance tests (entirely untuned) are showing ~100 GBps 
read and ~100 GBps write between a Mac and a RAID-1 GbE NAS box, and 
that's undoubtedly being throttled by the switched GbE connection.

> It seems to me that a speedier file system and backup program will be 
> needed as VMS moves into larger storage capacities.

Ayup. And beyond the file systems, likely also work in the various 
associated device driver I/O stacks. Packet-processing times being 
inversely proportional to bus speeds.  ~672 ns per GbE frame, ~67.2 ns 
per frame 10 GbE, IIRC. Figure out your processor cycle count from your 
clock-speed, and from there the instruction rate and the maximum number 
of instructions per the frame / packet / buffer if the host drivers are 
not throttling, and if the NIC isn't throttling on your behalf.

With the production release in a year or three, we'll get a better idea 
how much faster OpenVMS running on x86-64 hardware has gotten, as 
compared with Itanium.



-- 
Pure Personal Opinion | HoffmanLabs LLC