topic Re: Disk Errors in Operating System - OpenVMS

Disk Errors

MJ26 — Thu, 16 Nov 2006 10:28:02 GMT

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.

Re: Disk Errors

Ian Miller. — Thu, 16 Nov 2006 10:39:49 GMT

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

Re: Disk Errors

MJ26 — Thu, 16 Nov 2006 10:57:57 GMT

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.

Re: Disk Errors

Robert Gezelter — Thu, 16 Nov 2006 10:59:02 GMT

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

Re: Disk Errors

Ian Miller. — Thu, 16 Nov 2006 11:44:43 GMT

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.

Re: Disk Errors

Jim_McKinney — Thu, 16 Nov 2006 11:59:10 GMT

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

Re: Disk Errors

MJ26 — Thu, 16 Nov 2006 12:04:38 GMT

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.

Re: Disk Errors

Jan van den Ende — Thu, 16 Nov 2006 13:20:34 GMT

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

Re: Disk Errors

pcseunix — Fri, 17 Nov 2006 02:29:00 GMT

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.

Re: Disk Errors

GuentherF — Fri, 17 Nov 2006 12:21:14 GMT

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