inconsistent highwater mark and EFBLK

[Andrea Arthur]

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.

[John Abbott_2]

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

and they will go away.

J.

[Hein van den Heuvel]

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]

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]

> 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.

[Volker Halle]

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]

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

[John Abbott_2]

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 :-) !

[John Abbott_2]

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

[Volker Halle]

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]

Here you go Volker...

J.

[John Abbott_2]

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

[Jim_McKinney]

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 · Accepted solution]

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.

[Andrea Arthur]

Thank you all for your contributions.

[Volker Halle]

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]

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]

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

[Volker Halle]

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]

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

[John Abbott_2]

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.

[Volker Halle]

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]

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

[Stanley F Quayle]

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?

[Ian Miller.]

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

:-)