vax 7620

[vmsserbo]

I received 6 errors on one of our disks during nightlt backup. Received following email message.

-SYSTEM-F-FORCEDERROR, forced error flagged in last sector read -SYSTEM-F-FORCEDERROR, forced error flagged in last sector read

I have enclosed the anal/err log Can someone take at look at this and tell me if I should place a call to our hardware support or just monitor the disk.

Thanks!

[Karl Rohwedder · Accepted solution]

Miles, have a look at HELP/MESSAGE FORCEDERROR.
The data in some sectors may be false. You may try an ANA/DISK/REP and check/restore the files.
If the errorcount increase on this disk, I would swap it.

regards Kalle

[Robert Gezelter]

Miles,

I would recommend that you take a backup of that disk as soon as is practical. Then I would do as Kalle suggested.

Disk errors sometimes presage a total disk failure, other times the disk is in overall good shape, just a bad spot developed on the disk. There is no way of knowing which situation is which until it is too late.

Personally, I just had just such a situation on my laptop with Windows during the OpenVMS bootcamp -- a file in the boot sequence had a soft error and the machine would not boot. The CDROM reader and installation CDROM were back in New York. It only took a few minutes to run a surface scan to correct the (appearantly) soft error, but it created an anxious few days.

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

[vmsserbo]

I did do a disk/anal/repair on the disk. I logged in this morning and the errors did not increase. Thanks for the suggestions!

Miles

[Ian Miller.]

try also ANAL/DISK/READ which will read all in use blocks. you have a bad block or two in a file somewhere

[vmsserbo]

When I run the anal/disk/read $1$dua4:
What wil lI see, also when I run anal/disk/repair $1$dua4:

Will I see anything? It just came back with the prompt again?

Thanks!

[vmsserbo]

When I run the anal/disk/read $1$dua4:
What wil lI see, also when I run anal/disk/repair $1$dua4:

Will I see anything? It just came back with the prompt again?

Thanks!


Also, I got these messages runimg the read?
%ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS
-SYSTEM-W-NOSUCHFILE, no such file
%ANALDISK-W-READFILE, file (57,49,0) [RMS3]ODEDATA.DAT;1
error reading VBN 191753
-SYSTEM-F-FORCEDERROR, forced error flagged in last sector read
%ANALDISK-W-READFILE, file (57,49,0) [RMS3]ODEDATA.DAT;1
error reading VBN 191754
-SYSTEM-F-FORCEDERROR, forced error flagged in last sector read

[Karl Rohwedder]

regarding QUOTA.SYS: this a normal informational message, indicating that diskquota is not enabled on this volume

the other message indicate which files are suspect, you recover them from a backup, if nec.

regards Kalle

[vmsserbo]

So, It really isn't an error with the disk? just a corrupt file?

[vmsserbo]

DOESN'T THE ANAL/DISK/REPAIR $1$DUA4:

FIX THAT FILE??

[Karl Rohwedder]

The file may be sort of corrupt, the filesystem can no longer guarantee its correctness and flags this to you with forced errorflag. So its up to you to decide, good or bad.

This may be a single error on this disk which has further consequences. But these error often indicate a problem with the disk, hence the advice to monitor the error rate (and make a backup as long as its possible).
The ANA/DIS/REP cannot repair such errors, it repairs logical errors in the disk structure, e.g. lost file (files that are not listed in a directory).

regards Kalle

[vmsserbo]

Hi,

We got the same error as before on the same device. dua4 has 11 errors instead of 6. Is it safe to assume that there is a bad spot on the disk, or are the files bad.

This is the error message!

%BACKUP-E-READVERR, virtual read error on file [RMS3]ODEDATA.DAT;1 at block 191^
-SYSTEM-F-FORCEDERROR, forced error flagged in last sector read
%BACKUP-E-READVERR, virtual read error on file [RMS3]ODEDATA.DAT;1 at block 191^
-SYSTEM-F-FORCEDERROR, forced error flagged in last sector read
%BACKUP-I-STARTRECORD, starting backup date recording pass

[Ian Miller.]

Did you restore [RMS3]ODEDATA.DAT;1 from backup? At least one block of this file is not readable and I expect this makes it corrupt.
It may be after deleting that file (which will cause a bad block scan and possible re-vectoring of blocks) and restoring from backup then the disk could be ok.
After doing that I would watch it carefully and consider replacing it if you can obtain a replacement.

[Duncan Morris]

Miles,

if you examine your original error log, you will see the pattern of events.
Initially the system flagged a problem reading from logical block 192745 on the disk, but appears to have got over the problem.

Later it encounters a problem reading block 192788, which it cannot overcome.

FORCE ERR, DATA NOT RECOVERED
BAD LOGICAL
REPLACEMENT ATTEMPTED, BLOCK
_ VERIFIED BAD

It therefore does a "bad block replacement" operation. It attempts to recover the data in the bad block, but is unable to:-

DATA ERROR
UNCORRECTABLE ECC ERROR

It therefore flags the replaced block with a Forced Error flag to indicate that data has been lost.

The same problem occurs with the next lbn, 192789 and another forced error is flagged.

Subsequently, when you attempt to read the affected file, you get error reports for virtual blocks 191753/4 of ODEDATA.DAT.

The forced error flags will remain until those blocks of this file are rewritten.

You should recover the data in this file from backup.

If you use ANAL/RMS, you can determine whether the corrupt blocks are part
of a data area, and index area, or in an used area of the file.

If you are lucky, and the corruption is not in a data area, a simple CONVERT operation
will probably be able to read all the data and reconstruct the file.

There are a number of utilities written by members of this forum to rewrite specific blocks within a file, BUT this is not a trivial operation, and should only be undertaken by someone with a good knowledge of RMS and the underlying data structure of the file involved.

Duncan

[vmsserbo]

Here is the anal/err log that I did. Thanks for all your help.

[vmsserbo]

Duncan,

What would the convert command be?

[vmsserbo]

I did the anal/rms. I have enclosed an attachment for the results. Please take a look at it and see if I can run a convert to correct the problem as indicated by Duncan.

If I can, what is the command I have to use

Thanks!

[Duncan Morris]

Hi Miles,

sorry for the delay, I've been out of the office.

Judging by the key descriptor pointing to the root VBN for your index being

Root VBN: 845557

and, given the fact that the bad data is in the bucket commencing VBN 191747, it would seem most likely that the corruption is in a data section of the file rather than an index area.

It looks like you need to recover the file from backup and apply subsequent updates.

As your file updates do not seem too frequent, you may find that an older backup of the file has a good copy of the affected bucket. The file has not been converted since November 2004, so there is a hope that the last good backup has the same data in that location.

You would need a local expert to attempt to copy the required bucket from one version of the file to the other. It is also very dependent upon the volatility of the data in the file, and the frequency of your backups.

Regards,

Duncan

[vmsserbo]

Thanks!

We did have to restore from a good backup

ThankYou all for your advise!

Much Appreciated!