HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

inconsistent highwater mark and EFBLK

 
SOLVED
Go to solution
Andrea Arthur
Occasional Advisor

inconsistent highwater mark and EFBLK

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.
25 REPLIES
John Abbott_2
Esteemed Contributor

Re: inconsistent highwater mark and EFBLK

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

and they will go away.

J.
Don't do what Donny Dont does
Hein van den Heuvel
Honored Contributor

Re: inconsistent highwater mark and EFBLK


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.
Andrea Arthur
Occasional Advisor

Re: inconsistent highwater mark and EFBLK

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.
John Abbott_2
Esteemed Contributor

Re: inconsistent highwater mark and EFBLK

> 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.
Don't do what Donny Dont does
Volker Halle
Honored Contributor

Re: inconsistent highwater mark and EFBLK

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.
Wim Van den Wyngaert
Honored Contributor

Re: inconsistent highwater mark and EFBLK

John Abbott_2
Esteemed Contributor

Re: inconsistent highwater mark and EFBLK

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 :-) !
Don't do what Donny Dont does
John Abbott_2
Esteemed Contributor

Re: inconsistent highwater mark and EFBLK

... could it be for files that have a ALQ not equal to EOF ?
Don't do what Donny Dont does
Volker Halle
Honored Contributor

Re: inconsistent highwater mark and EFBLK

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.
John Abbott_2
Esteemed Contributor

Re: inconsistent highwater mark and EFBLK

Here you go Volker...

J.

Don't do what Donny Dont does
John Abbott_2
Esteemed Contributor

Re: inconsistent highwater mark and EFBLK

One thing wrong... the file entry link count is zero.
Don't do what Donny Dont does
Jim_McKinney
Honored Contributor

Re: inconsistent highwater mark and EFBLK

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".
John Abbott_2
Esteemed Contributor
Solution

Re: inconsistent highwater mark and EFBLK

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.
Don't do what Donny Dont does
Andrea Arthur
Occasional Advisor

Re: inconsistent highwater mark and EFBLK

Thank you all for your contributions.
Volker Halle
Honored Contributor

Re: inconsistent highwater mark and EFBLK

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.
Cass Witkowski
Trusted Contributor

Re: inconsistent highwater mark and EFBLK

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?
Stanley F Quayle
Valued Contributor

Re: inconsistent highwater mark and EFBLK

How about fixing ANALYZE/DISK/REPAIR so it repairs the error?
http://www.stanq.com/charon-vax.html
Volker Halle
Honored Contributor

Re: inconsistent highwater mark and EFBLK

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.
Jan van den Ende
Honored Contributor

Re: inconsistent highwater mark and EFBLK

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
Don't rust yours pelled jacker to fine doll missed aches.
John Abbott_2
Esteemed Contributor

Re: inconsistent highwater mark and EFBLK

I'm with Volker, I wouldn't want a backup restore or an anal/disk operation take ages. We have GB sized DB container files that are marked /nobackup, they are usually locked (db up - phew!) but sometimes on development the database is down, if a backup is taken I don't want them included and for a restore I would not like to have binary zeros written.

just my 2eur too!

J.
Don't do what Donny Dont does
Volker Halle
Honored Contributor

Re: inconsistent highwater mark and EFBLK

Jan,

maybe we should take the %ANALDISK-I-BADHIGHWATER, message as just as is is: an informational message, that there are files on the disk, which have not been overwritten by zeroes.

Once you understand what the message means, things get much clearer...

Volker.
Jan van den Ende
Honored Contributor

Re: inconsistent highwater mark and EFBLK

Volker,

I could well live with that, _IF_ the message itself and/or the HELP on it would explain it clearly, clear also to those who encounter it for the first time, and have not gone through this or similar "outside" explanations.

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Stanley F Quayle
Valued Contributor

Re: inconsistent highwater mark and EFBLK

How about ANALYZE/DISK/REPAIR=HIGHWATER, with the default behavior of /REPAIR be NOHIGHWATER?

Also, while we're hacking on ANALYZE/DISK, how about suppressing "error" about QUOTA.SYS if quotas are not in use?
http://www.stanq.com/charon-vax.html
Ian Miller.
Honored Contributor

Re: inconsistent highwater mark and EFBLK

http://www.hpuseradvocacy.org/node/add/issue/43

:-)
____________________
Purely Personal Opinion