RL02-USB Controller Status/Problem

[Don North]

On 4/7/2015 12:25 PM, Johnny Billquist wrote:
> On 2015-04-07 20:54, Pete Turnbull wrote:
>> On 07/04/2015 19:26, Johnny Billquist wrote:
>>>> Well, yes, it's still bad, and still there, but all the RT-11 utilities
>>>> use the substitute block.
>>>
>>> So COPY/DEV is essentially only usable for opying RT-11 disks on RT-11
>>> systems. :-)
>>> Nothing wrong with that, mind you.
>>
>> Well, no, actually; I've been using it (under RT-11 V5.7) to copy other
>> OS disks (mainly 7th Edition Unix) because it does that perfectly well
>> :-)  When the DL.SYS driver sees a disk changed, it reads the
>> manufacturing defect list so it's still good to copy most disks.
>
> But since the 7th edition Unix most likely do not treat the bad blocks the 
> same way as RT-11 does (skipping bad blocks), that means blocks will get 
> renumbered, and 7th edition will end up with a very corrupt and broken file 
> system.
> Essentially, this will only work well if you don't have any bad blocks on the 
> device.
>
> Just because you have a manufacturer bad block list on the disk, that does not 
> mean that different OSes handle the disk the same way.
>
> Let me give you a very silly example.
> Let's say we have a file system where each disk block points to the next disk 
> block in a file, and that the OS address each disk block in an absolute 
> manner. Bad blocks do not affect the block numbering.
>
> Let's then say that we have the following 5 blocks:
>
> Block #        Content
> n:        n+1
> n+1:        n+3
> n+2:        <bad block>
> n+3:        n+4
> n+4:        0 (EOF)
>
> Now, if RT treats this as skipping over the bad blocks, it would skip n+2, 
> while n+3 would on the target device become n+2. However, block n+1 still 
> points to n+3, so now we skip over one block of the file. Which means we 
> corrupted the disk.
>
> I could create a whole bunch of similar scenarios, but I'm sure you can too. :-)
>
>     Johnny
>

I don't see any way that bad blocks can just be skipped over in the numbering 
system. This would mean you had no reasonable way of doing random block access 
to the RL0x device without some type of lookup table.

RL0x does head/cylinder/sector addressing, so a direct block address could be 
decomposed into a specific H/C/S by a simple set of equations. If you throw 
skipping arbitrary bad sectors in the mix this no longer works.

So I see that replacement of bad sectors inline (using the '144 mapping table 
and data) as the only reasonable approach.

My opinion of course.