How to repair a corrupted BADBLK.SYS file

[rbeasley3]

I have a (Charon-VAX) emulated VAX 4000-90 system, with a system disk that has a corrupted [000000]BADBLK.SYS file. The system is running VAX/VMS V5.5-2H4.

I tried to restore it from an image backup save-set that was taken the day before the file was corrupted, but BACKUP was unable to restore the file, even though the file is clearly listed in the backup saveset listing, and the file was NOT marked NOBACKUP. In fact, my restore command (BACKUP/LOG <save-set>/SAVE/SELECT=[000000]*.SYS SYS$LOGIN:*.*) is ignoring all the *.SYS files directly under [000000] -- none of the other .SYS files can be copied from the save-set either. I can restore other files listed in the save-set, but not those. So now I'm trying to find another way to restore or repair this one file.

ANALYZE/DISK/REPAIR didn't even list BADBLK.SYS, so I'm wondering if I should use ANALYZE/MEDIA to re-create a brand new version of BADBLK.SYS. Or I should use any other method. I don't want to restore the entire disk from the image save-set, since BADBLK.SYS is the only file that I found that was corrupted..

Please advise.

Thanks in advance,

- Ron

[Steven Schweda]

> [...] a corrupted [000000]BADBLK.SYS file. [...]

   I'll bite.  How, exactly, did you reach that conclusion?  As usual,
showing actual actions (commands) with their actual results (error
messages, ...) can be more helpful than vague descriptions or
interpretations.  Copy+paste is your friend.

> [...] BACKUP was unable to restore the file, [...]

   "unable" is not a useful problem description.  It does not say what
you did.  It does not say what happened when you did it.  See "As usual
[...]", above.

   My understanding of VMS file systems is, at best, vague, but I'd
expect a file like BADBLK.SYS to be handled exclusively by the file
system or other system software, and not to be susceptible to
manipulation by a user.

> [...] I don't want to restore the entire disk from the image
> save-set, [...]

   I would not be amazed if that were required.

> [...] since BADBLK.SYS is the only file that I found that was
> corrupted.

   "found" _how_, exactly?

> [...] ANALYZE/MEDIA [...]

   Might be worth a try, but I wouldn't expect much.  I thought that the
whole bad-bkock scheme applied only to obsolete hardware.  And that the
Bad Block Locator Utility (BAD) was data-destructive.

[rbeasley3]

Hello, Steve:

To answer your questions:

I'll bite.  How, exactly, did you reach that conclusion?  As usual,
showing actual actions (commands) with their actual results (error
messages, ...) can be more helpful than vague descriptions or
interpretations.  Copy+paste is your friend.

Answer: I used the ANALYZE/RMS command, as follows:

TXPRPI$ **bleep**/rms _TXPRPI$DKA0:[000000]BADBLK.SYS;1

Check RMS File Integrity 2-DEC-2023 09:45:41.90 Page 1
_TXPRPI$DKA0:[000000]BADBLK.SYS;1FILE HEADER

File Spec: _TXPRPI$DKA0:[000000]BADBLK.SYS;1
File ID: (3,3,0)
Owner UIC: [1,1]
Protection: System: RWED, Owner: RWED, Group: RE, World:
Creation Date: 20-JUL-1993 10:22:54.21
Revision Date: 2-JUN-1998 08:42:24.32, Number: 7
Expiration Date: none specified
Backup Date: 24-NOV-2023 16:16:43.01
Contiguity Options: none
Performance Options: none
Reliability Options: none
Journaling Enabled: none

RMS FILE ATTRIBUTES

File Organization: sequential
Record Format: fixed
Record Attributes:
Maximum Record Size: 512
Longest Record: 512
Blocks Allocated: 17, Default Extend Size: 0
End-of-File VBN: 18, Offset: %X'0000'
File Monitoring: disabled
Global Buffer Count: 0
*** Attempt to read block with invalid VBN 13.
Unrecoverable error encountered in structure of file.The analysis uncovered 2 errors.

**bleep**/RMS _TXPRPI$DKA0:[000000]BADBLK.SYS;1

2.  > [...] BACKUP was unable to restore the file, [...]

   "unable" is not a useful problem description.  It does not say what
you did.  It does not say what happened when you did it.  See "As usual
[...]", above.

Answer: I issued the following commands in an attempt to copy BADBLK.SYS from the image save-set that was created the day before the corruption was discovered:

TXBCK1$ mount/for lma22:
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-MOUNTED, VR0623 mounted on _$1$LMA22: (TXBCK1)
TXBCK1$ back/log LMA22:0234BA51113.FUL/save/sele=badblk.sys *.*
%BACKUP-W-NOFILES, no files selected from LMA22:[000000]0234BA51113.FUL;

Before I tried to pull a copy of BADBLK.SYS from that save-set, I issued a

"BACKUP/LIST=0234BA51113.LIS   LMA22:0234BA51113.FUL/save" command to generate a listing of that save-set. I then issued a SEARCH command to verify that BADBLK.SYS was in the save-set:

TXBCK1$ sear 0234BA51113.lis badblk.sys
[000000]BADBLK.SYS;1 17 8-MAR-2007 08:00
TXBCK1$ 

That's what I meant I stated that BACKUP was unable to restore the file. The file is clearly in the save-set, but the errror message from the "BACKUP/LOG" command suggests BACKUP was unable to find or select the file.

3. 

> [...] since BADBLK.SYS is the only file that I found that was
> corrupted.

   "found" _how_, exactly?

ANSWER:  I ran a batch job that issues either a "ANALYZE/RMS" or an "ANALYZE/IMAGE" command on the latest version of each file (depending on if the file is an .EXE file or not) on the system disk  (excluding files that were previously discovered to have errors). BADBLK. SYS was the only file that had errors on the system disk. 

The ANALYZE/MEDIA command (by default) WILL detroy data on the disk -- unless you specify "/NOEXERCISE/BAD_BLOCKS" 

Hope these explanations help.

- Ron

[rbeasley3]

Steve,

After I submitted my response to you, I noticed some "**bleep**s that were inserted in my response in place of the word "ANALYZE".

I have no idea how those **bleep** got in there.

- Ron.

[Volker Halle]

Ron,

the '*bleep*s are an attempot of the forum software against 'bad language'

You might want to read up on BADBLK.SYS in (6926) Disk Bad Block Processing? - VSI OpenVMS Forum (vmssoftware.com)

There could be 'bad blocks' included in that file. If you'll read them, you could encounter disk read errors. Do you want that to happen ?

This file is one of the OpenVMS reserved file and best to be left alone. If it closely tied to the physical disk, on which it resides, so BACKUP and restore of that file would not make much sense.

Volker.

[rbeasley3]

Hello, Volker. 

As far as the *bleep* are concerned, I think that must have happened because I abbreviated the "ANALYZE" command. It didn't occur to me that my abbreviation would be misinterpreted as "bad language". I assure you no "bad language" was intended in my posts.

The fact that BADBLK.SYS is a special file that gets created as part of the file system when disks are initialized is what I suspected as the reason why I couldnt' restore it. None of the other .SYS files under the MFD [000000] could be restored either for the same reason. So that answers that question.

Thanks for the link from VSI on BADBLK.SYS. I'll check it out.

It turns out this particular VAX is an emulated (Charon-VAX) system on a Windows host, so it doesn't have "real" (physical) RZ disks. So the whole concept of bad blocks may not apply in the same way as it would for a physical VAX. I'm going to check the Stromasys manuals to find out how BADBLK.SYS should be managed in an emulator environment (or even if it matters).

Thanks, again Volker for your help -- as always!!

- Ron Beasley

[Volker Halle]

Ron,

as your BADBLK.SYS file contains > 0 blocks, you could try a

$ DUMP/HEAD/BLOCK=COUNT=0 _TXPRPI$DKA0:[000000]BADBLK.SYS

this will tell you the LBNs of those 'bad' blocks.

Creation Date: 20-JUL-1993 10:22:54.21
Revision Date: 2-JUN-1998 08:42:24.32, Number: 7

AFAIK, there was no CHARON-VAX back in 1993 or even 1998 (the first CHARON-VAX was sold in 2000) ! Maybe this file got copied during the physical disk migration to CHARON-VAX ?

Volker.

[Steven Schweda]

> It turns out this particular VAX is an emulated (Charon-VAX) system on
> a Windows host, [...]

   I have a SIMH VAX on a Mac, running V7.3, which I thought was doing
nicely, but a quick **bleep**/DISK spewed a torrent of complaints:
%ANALDISK-W-MULTALLOC, %ANALDISK-W-LOSTHEADER, and ppssibly others.  Its
BADBLK.SYS was 9 blocks, and a DUMP of that included a few complaints
like this:

Dump of file DUA0:[000000]BADBLK.SYS;1 on 3-DEC-2023 20:34:48.24
File ID (3,3,0) End of file block 9 / Allocated 9

Virtual block number 6 (00000006), 512 (0200) bytes

%SYSTEM-F-ILLBLKNUM, illegal logical block number

   This stuff was all created on this virtual system, no copying from
another system.  Perhaps repeated instances of shut-off rather than
shut-down cause more trouble than one might hope.

[Hein_vdHeuvel_d]

This quesiton, with much less details unfortunately, was cross-posted in the VSI Forum as:

https://forum.vmssoftware.com/viewtopic.php?f=13&t=8919

My answer there was:

Huh? Is this question an early April Fools joke or apprentice rock fetch? Or simply overthinking things?

ANALYZE/RMS on badblk.sys is utterly meaningless.
This file contains all the known bad blocks on the volume. It has no RMS structure as such to analyze and any chunk of block read is _supposed_ to give a hardware read error. As block allocations are whole clusters some blocks will be readable but have random contents.

Don't worry, by happy.
Well... except that disks aren't supposed to have visible bad blocks no more, so if the badblk.sys file has any allocation then there may be a deeper, underlying issue.

Hein.

[rbeasley3]

Hello, Volker.

The DUMP command showed only one LBN, which did turn out be bad. I re-ran the DUMP command, but without any qualifiers, and that's when I got the following error message for five (5) of the 17 virtual blocks in the file:

%SYSTEM-F-ILLBLKNUM, illegal logical block number

So the question now is how to fix it.  But beyond that,  here's another question:

Does BADBLK.SYS files even matter anymore? Is BADBLK.SYS even worth fixing?

The disk in question is an emulated RZ59, and the O/S is VAX/VMS v5.5-2H4, so I'm wondering if BADBLK.SYS files are even needed for this particular environment.

- Ron