High water marking

[Wim Van den Wyngaert]

I activate high water marking on a disk.
Then I create a file of 400.000 blocks on this disk. The command takes about 30 seconds. During this time, f$search hangs and f$file too.

It seems that the disk is locked (but not for dir).

Why ?

Is it possible that a database server (sybase) crashes because of it (e.g. too much outstanding IO for the given quotas) ?

[Ian Miller.]

I guess a writelock has been taken out on the disk so DIR is ok as it just reads.

re sybase - depends on how it handles quota failures - it should cope but...

[Wim Van den Wyngaert]

No writelock on the disk. I checked and could write a new file to the disk. But I couldn't delete it (hang again).

[Uwe Zessin]

No, not a general write lock as in MOUNT/NOWRITE - just a synchronization lock, e.g. on one of the bitmaps.

[Hein van den Heuvel]

You'll need to get a hold of the Kirby McCoy's "VMS File System Internals" book ISBN DP 1-55558-056-4 to read up all the gory details. Notably check out chapter 5.4.5 "Dynamic Highwater Marking".

The basic premiss is easy. Never allow a process to read a block from a fiel that was not writen too that file earlier. The protetcs against 'scavenging'. That is, it protects against soem job just askgn for a bunch of block and then reads those to see if there is something 'interesting' left behind from a prior usage of that block (while it was part of a different, now deleted or truncated file).
Sounds easy, but ia hard to do right in a full sharing environment. The system has optimizations to avoid writes as much as possibly, notably when it detects 'sequential only access'. However, if you just allocate a bunch of blocks for a non-sequential file, or write a block for out into the file, the XQP will erase' all intermediate blocks... while holding a volume lock! (This can probably be fixed using a lower level lock, but that is not how it is done today). So writes to a file that is already open can go on, but any volume operation will stall.
You have to understand the application/file-usage to decide whether high-watermarkign is really needed, and what the expected costs are. You are not the first one to be bitten by this (myself, I get a painfull reminder once every 3 years or so: Hmmm.. is the system down? no? then why is my 'DIR' hanging? Oh duh... HWM!).

Groetjes,

Hein

[Uwe Zessin]

Hein,
he said he could create a new file, but not delete it - isn't the former an operation on the volume, too?

Wim,
did you just create an empty file or did you write data, too?

[Jan van den Ende]

Hi all,

as I have come to understand things, it is working fine.
Maybe a monitor IO/item=que for the disk will illustrate.
Creating a file is OK. (should that be initially so as well, while the SET VOL/HIGH is still active? Or is this assuming the data present before issuing the command was and still is not that important? Or IS this what CREATE is doing: writing VERY much meaningless data? ) But then, the file gets deleted, and the full area of the disk that WAS the file, now first has to be (multiply?) written, so as to release only 'truely erased' disk blocks.
So, for a big file to delete, your 'hang' is simply waiting for an IO to complete, that is somewhere at the back of a BIG que of disk IO entries...

correct me if I'm wrong, but this is what I remember of the info way back when, when highwatermarking was introduced (somewhere V5-ish ? )

Jan

[Martin P.J. Zinser]

Hello Wim,

well the first question obviously is, do you have an applicaiton requirement to pre-zero
the diskblocks with Highwatermarking? If not,
having it enabled will generally incurr a penalty on random access files.

Greetings, Martin

[John Eerenberg]

> "Then I create a file of 400.000 blocks on this disk. The command takes about 30 seconds. During this time, f$search hangs and f$file too.
It seems that the disk is locked (but not for dir).
Why ?"

The short answer is the highwater erase, f$search, f$file, etc. are, by design and many good reasons, single threaded through the FCP (File Control Primitive). For the FCP to erase 400,000 blocks takes roughly the time you mentioned. The detailed answer has already been given.

[Wim Van den Wyngaert]

It is still not clear. There is some kind of volume lock but I can still write (Uwe : with data blocks).

What are exactly the read/write locks that are taken ? A database system is much simplier to understand than RMS.

Second, I find it a bad implementation if applications are stalled because of it. Suppose you have a real time application that need to close a valve but can't do the job because some DBA is creating a big database file (would block the disk for several minutes or even hours).