RL02-USB Controller Status/Problem

Johnny Billquist bqt at update.uu.se
Tue Apr 7 14:25:07 CDT 2015

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. :-)


More information about the cctalk mailing list