7 Apr
2015
7 Apr
'15
10:35 a.m.
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:
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
On 2015-04-07 15:14, Pete Turnbull wrote:
Nevertheless, what I wrote is what RT-11 COPY does.
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. 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.