7 Apr
2015
7 Apr
'15
1:11 p.m.
On 2015-04-07 22:06, Don North wrote:
On 4/7/2015 12:25 PM, Johnny Billquist wrote:
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
On 2015-04-07 20:54, Pete Turnbull wrote:
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. On 07/04/2015 19:26, Johnny Billquist wrote:
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
> 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.