Disk Errors

[MJ26]

Hello,
I am new to the forum. I am running an analyze/disk/norepair and found the following issues on a disk:

%ANALDISK-W-ALLOCSET, blocks incorrectly marked free
LBN 4835952 to 4835963, RVN 1

%ANALDISK-W-BADHEADER, file (16121,381,1)
invalid file header

-ANALDISK-I-BAD_FIDSEQ, unexpected FID_SEQ field

%ANALDISK-W-LOSTHEADER, file (19425,9,1) B02000015.TRD;1
not found in a directory


I got a few of each of the previous messages, but I am just curious if these issues can be resolved without having to replace a disk. Any suggests are welcome. Thank you in advance.

[Ian Miller.]

ANAL/DISK/REPAIR should sort that out.
The files not in a directory will be put in [SYSLOST]

[MJ26]

I ran the analyze/disk/repair and I am still receiving the following:

%ANALDISK-W-LOSTHEADER

All of the other errors went away.

Also, I wanted to ask is it always good to run anal/disk/repair two times? I was told that.

[Robert Gezelter · Accepted solution]

Mark,

I agree with Ian. ANALYZE/REPAIR should be able to make the needed corrections to the data structures.

These errors do not necessarily indicate hardware disk errors. These are inconsistencies in the data structures maintained by the file system.

The most worrying message is the one about "blocks incorrectly marked as free". I would suggest checking as to which file actually has those blocks in use. If the blocks were marked as free incorrectly, it could mean that at one point, the files were doubly allocated.

Keep careful notes of the precise messages that you received, and a full, possibly physical backup of the disk would be a good idea.

If the problem recurs, then more investigation is definitely in order.

- Bob Gezelter, http://www.rlgsc.com

[Ian Miller.]

Are the LOSTHEADER messages always the same file and do you know what that file is ?

DFU is also good for this and can be quicker.

Do keep a note of what was reported and its worth working out what the files are.

[Jim_McKinney]

> do you know what that file is ?

And maybe "$ SHOW DEVICE/FILE disk" also shows that file? Perhaps /REPAIR is unable to cure a LOSTHEADER condition (by upating INDEXF.SYS and entering the file in [SYSLOST] directory) for an open file?

If this is the case then it's likely that the application holding the file open will likely clean-up/dispose of it once done.

[MJ26]

I ran the analy/disk/repair a second time, and all of the errors are repaired. I will monitor the disk status and let the forum know of any changes. Thanks everyone for all of your help and explanation. I will also keep a better record of issues when posting a question or problem on here. Thanks again.

[Jan van den Ende]

Mark,

to begin with,

Welcome to the VMS forum!

%ANALDISK-W-LOSTHEADER is only a warning (indicated by the -W- )
A typical way to achieve this situation, is by replacing an INSTALLed file, and purging while not all references are gone yet.
@VMSINSTALL, and answering the default YES to the purge question, is a quite common way to generate it. An example of a bad choice of default answer: HIGHLY disadvisable, especially in cluster!

I do agree with Ian and Bob on the potentially bad situation with ALLOCSET.

hth

Proost.

Have one on me.

jpe

[pcseunix]

It looks to me that you're running this on a /SYSTEM mounted volume, and that there is activity on the volume. ANA/DISK does not lock the volume (/REPAIR does, though), so what you may be seeing is a volume that is changing underneath the ANA/DISK.

[GuentherF]

Always use ANALYZE/DISK/LOCK to get a consistent view at the disk volume. Using /NOREPAIR does not lock the volume and thus may display misleading errors. So the errors reported from the first command execution most likely were caused by disk activities while the analyze ran.

/Guenther