RL02-USB Controller Status/Problem
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
>>>>> 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. :-)
> 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
> 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.
More information about the cctalk