How to repair a corrupted BADBLK.SYS file

[rbeasley1652]

I support an (Charon-VAX) emulated VAX/VMS system. The BADBLK.SYS file on the system disk got corrupted recently. The "ANALYZE/RMS" command revealed errors in that file. I'm concerned what's going to happen the next time a bad disk block is found on that disk. Since it's being emulated on a Windows system, any "bad disk blocks" found will probably be the Windows disk (not a physical VAX disk), but the emulator will probably treat it as if the bad block is on a "RZ59" disk.

Now the read the VSI forum topic titled: (6926) Disk Bad Block Processing? - VSI OpenVMS Forum (vmssoftware.com), which describes how bad blocks found on a disk get "re-vectored" and placed into the BADBLK.SYS file so they don't get used for any files. But what happens when BADBLK.SYS is bad? How will the bad block processing work then? Is there a way to repair the BADBLK.SYS file without having to restore the entire disk? I looked at the "ANALYZE/MEDIA/NOEXERCISE/BADLOCKS" command, but it seems that command doesn't fix the BADBLK.SYS file. I also tried to restore BADBLK.SYS from a recent backup save-set, but the BACKUP command skipped restoring any of the .SYS files under the MFD, since those are reserved/special files unique to the disk when that disk was "initialized".

Any ideas?

Thanks in advance for any help I get!!

- Ron

[hein]

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.

note: This topic was cross-post in the HPE ITRC forums as:
https://community.hpe.com/t5/operating- ... -p/7202005

Hein.

[rbeasley1652]

Hello, Hein.

FYI:

This was neither an "early April Fools joke" or an "apprentice rock fetch". This was an honest question I asked on this forum.
I have used "ANALYZE/RMS" on the BADBLK.SYS files on other disks on this same system, and that command worked on all of those BADBLK.SYS files -- without any warning or error messages. But if your point is that "ANALYZE/RMS" is not a valid method to test the integrity of BADBLK.SYS files, I understand now.

Thanks for the link in the HPE ITRC forums that you provided -- I'll check there.

- Ron

[abrsvc]

Ron,

To make matters even worse, the fact that this is running in an emulated environment makes any entry in this file meaningless and suspect of overall corruption. This file would be updated when a block is found to be bad from a hardware sense. This is not possible in an emulated environment as the "block" would be file contents rather than a hardware disk block. Questions like this are more likely to be resolved through the emulator provider rather than VSI especially since VSI does not support VAX systems.

Dan

(Disclosure: I work for Stromasys an emulator provider)

[hein]

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

It might matter, but it cannot ever be 'fixed' it is supposed to be broken. As the name suggest it 'captures' bad blocks though allocation (mapping pointers in its header). The only reasonable command on it is DUMP/HEAD /NOBLOCK which gives you an indication of which the clusters which contain blocks which the file systems has reason to be are not readable or contain unreliable data. It has no records as such it has no data as such.

>> I have used "ANALYZE/RMS" on the BADBLK.SYS files on other disks

I'm sure you did, but it is utterly meaningless.
The command is expected to return errors if the file has any block allocated to it. That's all.

Hein.

[hb]

For each ODS-2/5 disk, the BADBLK.SYS file always contains the last logical blocks, that do not make up a full disk cluster (unfortunately, DUMP/HEADER of BADBLK.SYS shows retrieval pointers for a full cluster).

This may be what you are seeing. As far as I know, this has always been the case, whether you had a real disk or a virtual disk.

ANALYZE/RMS will report an error like

Code: Select all

***  Attempt to read block with invalid VBN 11.
        illegal logical block number

This VBN maps to the first LBN outside of the disk.

If the disk size is a multiple of the disk cluster, then BADBLK.SYS contains no LBNs and ANALYZE/RMS reports no error.

As Hein said, don't worry ...