topic Re: inconsistent highwater mark and EFBLK in Operating System - OpenVMS

inconsistent highwater mark and EFBLK

Andrea Arthur — Mon, 20 Mar 2006 09:55:51 GMT

Is there anything I can do to get rid of the following errors that ana/repair doesn't fix?

File (2540,2,1) PAGEFILE.SYS;2
inconsistent highwater mark and EFBLK
File (2541,1,1) SWAPFILE.SYS;2
inconsistent highwater mark and EFBLK

Is this indicative of a more significant problem?

This error appears after an image restore of the system disk following an error file header full.

Re: inconsistent highwater mark and EFBLK

John Abbott_2 — Mon, 20 Mar 2006 10:06:16 GMT

Issue a $ set file/own=[current_owner] PAGEFILE.SYS;2,SWAPFILE.SYS;2

and they will go away.

J.

Re: inconsistent highwater mark and EFBLK

Hein van den Heuvel — Mon, 20 Mar 2006 11:03:46 GMT

I suppose the inconsistency was triggered due to 'nobackup' settings for those file?

(See help SET FILE/BACK and help BACK/IGNO)

How about just deleting those files?

And maybe $set file/end... but if HWM is enabled then this will take a while (if you can even do that one those files on a live system).

[Sorry, no system to test/verify any of the above]

Hope this helps some,
Hein.

Re: inconsistent highwater mark and EFBLK

Andrea Arthur — Mon, 20 Mar 2006 12:20:05 GMT

Thank you.

I had created new page and swap files then deleted the old ones. I'm all set now.

But I am curious as to why a set file/owner would fix this issue.

Thanks again.

Re: inconsistent highwater mark and EFBLK

John Abbott_2 — Tue, 21 Mar 2006 04:43:48 GMT

> But I am curious as to why a set file/owner would fix this issue.

The files in question are typically marked /nobackup.

To be honest Andrea, it is puzzling. Simply "touching" the file appears to fix it (so other $ set file comands work too). The message fom anal/disk is only informational and doesn't even appear in the $ help/mess BADHIGHWATER

Sorry, can be of any more help. Maybe someone else can jump in for a good answer & 10 points :-)

J.

Re: inconsistent highwater mark and EFBLK

Volker Halle — Tue, 21 Mar 2006 05:05:41 GMT

Andrea,

the BADHIGHWATER message is issued from [VERIFY]VERIFY_INDEX based on the values of EFBLK, FFBYTE and HIGHWATER.

The source code comments says: DO NOT FIX IT! and ANAL/DISK/REPAIR doesn't ;-)

A DUMP/HEADER/BLOCK=COUNT=0 of such a file would be required to find out what's wrong.

Volker.

Re: inconsistent highwater mark and EFBLK

Wim Van den Wyngaert — Tue, 21 Mar 2006 05:27:12 GMT

Could it be this ?
http://groups.google.be/group/comp.os.vms/browse_frm/thread/4f76158eb4368e9c/a7594d9c05c27126?lnk=st&q=BADHIGHWATER&rnum=5&hl=en#a7594d9c05c27126

We discussed this in http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1008627 , it seems that many system disks are corrupted.

Wim

Re: inconsistent highwater mark and EFBLK

John Abbott_2 — Tue, 21 Mar 2006 06:43:50 GMT

All the files on the backup of my system disk & on data disks that are marked /nobackup report back with BADHIGHWATER when using anal/disk after a restore.

Some of them have been appearing for many moons now. Hey I'm not worried, cos there marked /nobackup & it's informational :-) !

Re: inconsistent highwater mark and EFBLK

John Abbott_2 — Tue, 21 Mar 2006 06:45:37 GMT

... could it be for files that have a ALQ not equal to EOF ?

Re: inconsistent highwater mark and EFBLK

Volker Halle — Tue, 21 Mar 2006 06:47:10 GMT

John,

if you could provide a DUMP/HEAD/BL=COUNT=0 of such a file, I might be able to tell what's wrong...

Volker.

Re: inconsistent highwater mark and EFBLK

John Abbott_2 — Tue, 21 Mar 2006 07:22:53 GMT

Here you go Volker...

J.

Re: inconsistent highwater mark and EFBLK

John Abbott_2 — Tue, 21 Mar 2006 08:43:27 GMT

One thing wrong... the file entry link count is zero.

Re: inconsistent highwater mark and EFBLK

Jim_McKinney — Tue, 21 Mar 2006 09:06:02 GMT

And the "Highest block written" (value 0) does not match the "Highest block" (value 488664) - presumably a side effect of BACKUP restoration on a file that was marked "no backup".

Re: inconsistent highwater mark and EFBLK

John Abbott_2 — Tue, 21 Mar 2006 09:32:08 GMT

Well spotted Jim !

... and when you do a $ set file/own=[x] foo.bar it writes binary zeros - the highest block written becomes 488664 and the anal/disk msg goes away.

This answers Andreas 2nd post question.

J.

Re: inconsistent highwater mark and EFBLK

Andrea Arthur — Tue, 21 Mar 2006 10:25:45 GMT

Thank you all for your contributions.

Re: inconsistent highwater mark and EFBLK

Volker Halle — Tue, 21 Mar 2006 12:46:41 GMT

Andrea,

this error is absolutley reproducable. Any WRITE access to such a file (a BACKUP of a file marked /NOBACKUP ending up with FH2$L_HIGHWATER=0), even a OPEN/READ/WRITE - although it may fail with an error %DCL-E-INVRFM - causes the file to be overwritten with zeroes and the HIGHWATER field in the file header to be updated.

The VERIFY_INDEX source code explicitly tries to skip reporting BADHIGHWATER for file headers with HIGHWATER=0 (IF ... .header[FH2$L_HIGHWATER] NEQ 0), but this logic somehow does not seem to work too well.

As we've now documented the reason for %ANALDISK-I-BADHIGHWATER and the explanation and workaround, it's time to close this thread.

Volker.

Re: inconsistent highwater mark and EFBLK

Cass Witkowski — Tue, 21 Mar 2006 19:45:45 GMT

before we close this thread...

John said that doing the set file writes zeros on the file and then the highwater mark is not the last block in the file.

Do I really want to write zeros on a in use page or swap file?

Re: inconsistent highwater mark and EFBLK

Stanley F Quayle — Tue, 21 Mar 2006 21:35:05 GMT

How about fixing ANALYZE/DISK/REPAIR so it repairs the error?

Re: inconsistent highwater mark and EFBLK

Volker Halle — Wed, 22 Mar 2006 01:29:18 GMT

Cass,

only the first and exclusive write accessor would cause the file to be overwritten with zeroes. SET FILE/OWN=xxx PAGEFILE.SYS will return SYSTEM-W-ACCONFLICT, if the pagefile is in use - so no risk here !

Stanley,

making ANAL/DISK/REPAIR 'repair' this error may need it to overwrite the file with zeroes, not sure whether you would want that to happen, as it may severely increase the amount of time for ANAL/DISK/REPAIR to finish and release the volume lock.

The same would apply to the possible idea of 'fixing' BACKUP, this would require BACKUP to overwrite the file with zeroes when restoring a file marked /NOBACKUP - not a good idea.

I would vote for including the message and an explanation and workaround in HELP/MESS BADHIGHWATER

Volker.

Re: inconsistent highwater mark and EFBLK

Jan van den Ende — Wed, 22 Mar 2006 03:22:17 GMT

Volker wrote

I would vote for including the message and an explanation and workaround in HELP/MESS BADHIGHWATER

How about making ANAL/DISK smart enough to recognise the mark /NOBACKUP, and just NOT report BADHIGHWATER those files?
After all, it IS just the intended behavior...

just my EUR 0.02

Proost.

Have one on me.

jpe