[Info-vax] free blocks

[Johnny Billquist]

On 2013-01-02 16:00, Bob Koehler wrote:
> In article <kbeubt$11e$1 at news.albasani.net>, Jan-Erik Soderholm <jan-erik.soderholm at telia.com> writes:
>>
>> And, this was/is not done dynamicaly, as far as I know. You had/have to run
>> a specific tool to check this (ANALYZE /MEDIA <dev>).
>
>     Nope.  You used anal/media to initialize the bad block file.  Bad
>     blocks discovered while the disk was in use were added to the bad
>     block file.
>
>     When VMS sees a bad block on write, it marks the block bad and writes
>     the data on a different block, and nevre uses that block again
>     (unless a tool like anal/media removes the mark).
>
>     When VMS sees a bad block on read, it marks the block bad and does the
>     best it can to read the data.  Each attempt to read will log I/O errors
>     on the device.  Deleting the file which contains the bad block will
>     cause the block not to be used again.  The application reading the
>     file will see I/O errors also, if it looks.
>
>     VMS doesn't need smarts to deal with revectoring disks differently.
>     VMS just never sees bad blocks reported from the hardware.

That depends on the disk and controller.
On an UDA-50, VMS have to do the revectoring of bad blocks. So bad 
blocks are reported to VMS. However, VMS do not use BADBLK.SYS to record 
them, but instead initiates a bad block replacement operation, trying to 
recover the data from the block, allocate a replacement block, and wrote 
the recovered data in that block, and finally revector the old bad block 
so that it never is seen as bad again.
After that, VMS don't have to worry about the bad block, the replacement 
block is automatically used by the controller and disk.

However, apart from that detail, I agree with all you write.

	Johnny