High water marking

[Jan van den Ende]

Well Wim,

Highwatermarking IS a very-high-security feature, to be used IF YOU NEED IT, explicitly AT THE COST of performance.
I guess yhis implies that highwatermarking and real-time functionality are mutually exclusive.
The way out of this dilemma is quite simple:
have the Sytem Manager make sure that your Highwatermark-requiring data are on another physical drive then your real-time files.

Jan

[Wim Van den Wyngaert]

Jan,

I disagree. Performance impact yes, blocking activities no. Simply a bad implementation. Even if there are workarounds.

I don't use it (I put it off where I see it). But used it for testing f$esrach.

[Martin Johnson]

It is not a bug, it's a feature!

These type of delays are typical of High Water Marking (HWM). If your applications are too sensitive to these delays then you have two options. One, turn off HWM, or, two, control your allocations, either by delaying large allocations to the off hours or breaking up the allocations into small chunks.

HTH
Marty

[Wim Van den Wyngaert]

Features should be documented. This is an implementation of which the side effects are not documented.

[John Gillings]

Wim,

This may not be OpenVMS at all. For some combinations of controller and disk drive, the HWM ERASE function is done in the drive itself. Just an I/O ERASE operation, rather than a series of writes to individual blocks, then wait for it to return (or, to be more precise, one I/O per allocated extent). So, all the stuff you CAN do may be the result of caching, or operations that the drive and/or controller can handle in parallel. Anything else just has to wait.

Bottom line, this IS the "performance impact" that the documentation talks about. You can argue about other ways of doing things, but they're all tradeoffs. That's what engineering is all about - picking the least worst choice.

With security, there are always nasty things to think about. For example, suppose we didn't lock the disk and zeroed the allocated blocks in small chunks, obviously that would take MUCH longer to complete. Apart from the cumulative cost of multiple I/O's, we'd have to write actual blocks, so data would need to be buffered and sent over the wires to the disk.

Worse, maybe it would be possible to request the CREATE asynchronously and access the blocks from a parallel thread, ahead of the ERASE fence, thus defeating HWM?

The engineers who designed this weren't complete morons, so if they've taken the fairly drastic step of holding a lock for a long time, it definitely wasn't without good reason. If you really want to know the answer, log a case with your local customer support centre and have it escalated into engineering. They will either say "of course! how stupid" and fix it, or they may explain why it has to be that way to guarantee security, or they may say "it has to be that way, but we're not going to tell you why becuase it involves security".

This is the burden of being OpenVMS. Other operating systems can take short cuts, possibly leaving security or reliability holes around the place, but we have to keep everything secure and failsafe, sometimes at the cost of performance.

[Wim Van den Wyngaert]

John,

Whatever the reason, no disk should be locked during a longer interval.

High water marking may not be used in financial market systems, real time applications and high availability systems, unless EVERYBODY is aware of the problem.

The performance impact that I found in the doc only talks about the extra IO for erasing those extents, not about the disk lock.

Wim

[Hein van den Heuvel]

> High water marking may not be used in financial market systems, real time applications and high availability systems, unless EVERYBODY is aware of the problem

hmmm... beg to differ.
Highwater marking may be MOST important for those financial market systems.
The impact is generally NOT found in day to day usage. For a 'normal' sequential file write no extra IO is needed. Hey, that's why the HWM is there! It's when you create the possibility to access beyond HWM that the erase is needed.
Any other real-time/oltp task on the disk with the files already open can just keep on reading/writing from those files there is no data IO lock (that concept does not even exist!).

Wim, is this question for the system you asked about for the caching? There you indicated sequential files were used a lot and indexed files where used little? Do you have a self-designed / supported data retrieval system to deal with? If so then indeed you will need to learn to deal with the 'fine print' like using the 'SQO' bit.

fwiw,

Hein.

[Wim Van den Wyngaert]

>The impact is generally NOT found in day to >day usage.

Any create/fdl (or extent) with a substantial file, any database file creation (sybase). This is very common on our site.

>Any other real-time/oltp task on the disk >with the files already open can just keep >on reading/writing from those files

All jobs creating files, re-opening files are blocked. Also very common. I tested with dcl read/key (file was open before create/fdl was started) and found that the procedure was still blocked during 11 seconds !!!

>Wim, is this question for the system you >asked about for the caching? There you >indicated sequential files were used a lot >and indexed files where used little? Do you >have a self-designed / supported data >retrieval system to deal with? If so then ?>indeed you will need to learn to deal with >the 'fine print' like using the 'SQO' bit.

Nope. Just trying to understand things without a cause.

If you try to buy some shares on the stock exchange, close valves of reffineries or other such stuff, you can miss those suspends.

Wim

[Hein van den Heuvel]

OK. Understood.

I must speculate that the slow READ/KEY was caused by the 2 to 5 IOS required to do so each had to wait in a large queue for the disk itself. ( 2 to 5 = index root, index lower-level-if-needed, data bucket, RRV-bucket-if needed)

Hein.

[John Eerenberg]

Wim,
If I may . . .

> I disagree. Performance impact yes,
> blocking activities no. Simply a bad
> implementation. Even if there are
> workarounds.

It seems like you are not accepting the reasons for blocking. We can debate the documentation's lack of clarity another time (acutally I agree with you).

Bottom line is if there is another way to do the erase without blocking other IO on the volume, how would you do it?

The goal of the erase is to prevent disk scavenging (there are other goals, but that's the one I am concerned with). What does a given application need? Does the application have to prevent disk scavenging? If one is worried about disk scavenging, then you have to erase before using the disk blocks. No other choice.

If you have another choice, how would you do it? This is not, as you claim, a "bad implementation" nor is it a design flaw or poor practice. Again, to guarantee security with the goal of disk scavenging, what would you do otherwise?

If you allow another IO to occur during the erase, you can bypass the attempted erase function, read the blocks that have not been erased (theoretically *all* of the blocks) and scavenge the data. The only kind of IO I could consider is a write IO. But the read IO's have to be blocked so to be safe, block all IO.

If this is a bad implementation, how would you guarantee security if you allow even one IO during the erase?