RL02-USB Controller Status/Problem

[Paul Koning]

> On Apr 7, 2015, at 1:21 PM, Pete Turnbull <pete at dunnington.plus.com> wrote:
> 
> On 07/04/2015 16:56, Johnny Billquist wrote:
>> On 2015-04-07 15:14, Pete Turnbull wrote:
>>> Actually COPY/DEV under RT-11 is commonly used, especially for non-RT-11
>>> packs.  I can't remember what RSX does, but RT-11 /does/ deal with the
>>> bad block table, by not copying the last track, and copying remapped
>>> blocks.
>> 
>> But that don't make sense. You cannot just move one block somewhere else
>> because it is bad on the target device. Or just ignore a block because
>> it is bad on the source device.
> 
> Nevertheless, what I wrote is what RT-11 COPY does.
> 
>> And "remapped" must be something very local to RT-11. RSX do not remap
>> any blocks. A block that is bad, is bad. It is still there.
> 
> Well, yes, it's still bad, and still there, but all the RT-11 utilities use the substitute block.

That certainly makes sense for RT-11.  After all, it uses a file structure in which all files are contiguous.  So the “mark them and avoid them” technique doesn’t work well, it means a 200 block free region with a single bad block centered in it would be unuseable for allocating a 101 block file.  So remapping selected block addresses to spares at the driver level (just below the file system) would avoid that.

In a sense, this amounts to a two-layer file system: the familiar one on top, and a thin address translation layer below it.  From the point of view of image copy, both layers are file system.  So a full pack image copy would be invalid for RT-11 just as it is invalid for other operating systems.  A structure aware image copy (akin to RSTS SAVRES) could be done easily: essentially that would mean copying the address space as seen at the top of the remap layer.  So the remap tables for the source and destination volumes would differ, but the conventional file system (directory etc.) would be the same for both.

	paul