7 Apr
2015
7 Apr
'15
8:25 a.m.
On Apr 7, 2015, at 8:41 AM, Pete Turnbull <pete at
dunnington.plus.com> wrote:
On 06/04/2015 23:54, Christopher Parish wrote:
No, DEC does not do that. At least not in RSX, as Johnny described, nor in RSTS.
In RSTS, creating a file system on a pack is done with the ?dskint? utility. One of its
functions is to perform a drive scan, writing and verifying all sectors with several data
patterns. If a sector is found to be bad, it is handled simply by allocating it to the
reserved file [0,1]badb.sys. This scheme works for all drive types, including those that
predate DEC Std 144. On packs that have a bad block table, the blocks listed in that
table are includes in the bad block list that dskint determines (I don?t remember if they
are checked anyway, or bypassed in the check).
I also don?t remember if there was a way to handle blocks going bad later. In principle,
yes; they could be allocated to badb.sys also. If so, a file system check (?onlcln?)
would find a double allocated block and let you delete the file that was affected.
The first drive type I know of that had anything resembling remapping is the RM80, with
the ?skip sector? feature, where each track had an extra sector, and a flag in the sector
header could be used to mark that sector as ?skip me and use the spare sector instead?.
The first real remapping appeared in MSCP, which makes sense because that is the first
time that DEC drives used logical addressing instead of hard cylinder/track/head
addressing. At first (UDA50), remapping was done largely in the driver, requiring a
quantity of code way larger than any other disk driver. In subsequent MSCP controllers,
it moved entirely into the controller and the host simply saw an error free logical block
space.
Given all this, an image copy of a disk is not valid, unless the destination disk is error
free. (Early packs usually were, which is why early PDP11 backup programs like ROLLIN did
use image copy.) If the destination disk has errors, the copying has to be at the file
system level, either by just copying all files one by one, or by doing an image copy that
works around destination flaws. The RSTS standalone backup program SAVRES is an example
of the latter.
paul
Progress is good on the RL02-USB controller.
I've gotten complete
operation working as expected with the usual tools for disk access
(badblocks, dd, etc.), and SIMH can access the real packs via the
controller's block device (i.e. attach rl0 /dev/sdX).
Very good! I want one :-)
The issue is most obvious when backing up and
restoring disk images.
Suppose I backup a pack with 1 bad sector. I have two choices of what
to do with the bad sector (specifically if it's a bad header), I
could skip the sector (reporting an IO error), or I could report all
zeros for the sector.
The usual trick of having the controller re-map
the bad sectors will
not work because the platters in the RL02 are removable.
DEC does it by having the driver software remap sectors.