[Info-vax] free blocks

[Johnny Billquist]

On 2013-01-02 19:52, Stephen Hoffman wrote:
> On 2013-01-02 18:35:51 +0000, Johnny Billquist said:
>
>> 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,
>
> AFAIK, BADBLK.SYS is still used.  That's where the blocks with
> uncorrectable read errors are "stored", pending eventual revectoring.

Cool. That is way more than I know. I know how it works in RSX, which 
don't use BADBLK.SYS. So, in VMS, the blocks get added, and then later, 
get removed again?

In RSX, if the MSCP driver gets a bad block error, it sends a message to 
RCT, the replacement control task, with the information about which 
block failed reading. RCT will then try to recover the data from the 
block, allocate a replacement, and then update all the info on the disk. 
I think all other I/O to that disk is suspended until the revectoring is 
complete.

>> 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.
>
> Once the write to the bad sector or the file delete happens, yes.

Well, the previous bad block should be mapped away right away. No point 
in letting that one hang around.
If the data could not be recovered, then you set the forced error bit on 
the block, which gets removed if the block is written.

Or so I seem to remember anyway.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol