RL02-USB Controller Status/Problem

Johnny Billquist bqt at update.uu.se
Tue Apr 7 15:11:18 CDT 2015


On 2015-04-07 22:06, Don North wrote:
> 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.

I just posted an answer to Paul explaining how OS/8 does exactly this: 
skip over bad blocks. It's actually not hard at all, and less costly 
than a lookup table.
But anyway, this is all theoretical. Unix do not have any such schemes. 
It essentially do the same things we've been talking about. When you 
find a bad block, you actually create a file containing that block, so 
that nothing else will accidentally use it later.
So it's not hidden or remapped in any way.

	Johnny




More information about the cctalk mailing list