8 May
2019
8 May
'19
7:47 p.m.
I'm just guessing here but I would suspect this had more to do with the
hardware capabilities of the tape system.
Not all tape drives could just pause to wait for more data then resume. If
the data wasn't being steamed fast enough the tape would have to resync
somehow which could even require rewinding and it's possible that was
either unsupported or just unreliable
On Thu., May 2, 2019, 12:41 p.m. Paul Koning via cctalk, <
cctalk at classiccmp.org> wrote:
On May 2, 2019, at 10:49 AM, Ethan Dicks
<ethan.dicks at gmail.com> wrote:
On Thu, May 2, 2019 at 8:13 AM Paul Koning <paulkoning at comcast.net>
wrote:
>> On May 1, 2019, at 10:58 PM, Ethan Dicks
<ethan.dicks at gmail.com>
wrote:
>> I think those were still true for V3.X.
I know we had a problem back
>> then with our backups where someone elevated the priority of the Tape
>> ACP over the Disk ACP (because it was faster) that left us with months
>> of corrupt backups.
>
> Wow, that reflects very badly on the engineering involved. Setting
priorities
wrong might cause things not to get done, or to take too long,
but it cannot ever be an excuse for data corruption.
Thinking back 35 years... it was that someone enabled the backup
operator account with SETPRI, allowing the operator to elevate the
priority of the script. What I think was happening was that the
script was grabbing buffers from the disk before they were filled and
slamming them out to tape. It definitely cut minutes off the backup
time, which is why it happened.
I'm sure the VMS wizards hadn't expected a user process to run at
priority 31 (IIRC) because anyone with SETPRI _surely_ had the wisdom
not to elevate above system processes.
Definitely a failure to think of ways users could abuse the system.
-ethan
More in particular, it is a design failure, relying on timing hacks rather
than explicitly and correctly passing ownership of data from producer to
consumer.
paul