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.