7 Apr
2015
7 Apr
'15
3:21 a.m.
This might become a long answer.
First of all, back when the RL drives were made, hardware handled bad
block management wasn't yet popular in that neck of the woods. So bad
blocks were/are visible to the software. In order to have some
management of this, DEC had a standard - DEC STD144, which described how
you kept track of, and managed, bad blocks.
If you ever wondered where the Unix program bad144 got its name from,
now you know (and the ultimate stupidness is NetBSD, where they decided
that only the x86 platform would have bad144, leaving the VAX - the only
hardware platform who actually had disks following the bad144 standard,
not having the bad144 program).
The STD144 reserves the last track of the device for pack information.
In there you have the pack serial number, and also the manufacturer bad
block list, and also the user bad block list. When/if new blocks are
detected after the pack is manufactured, they would be placed in the
user bad block list.
So, a EF pack would simply be a pack with no bad blocks from the
manufacturer. The manufacturer bad block list would contain no bad
blocks. This does not mean that the pack could not develop bad blocks later.
Now, a total imaging of one RL disk to another is not something you
should do. That would replace the pack serial number, in addition to the
issues with the bad block lists. Not to mention that different packs
have bad blocks in different places.
Sp, to get to the meat of it. No, bad blocks are not replaced, or mapped
away, or faked. The drive and controller can detect bad blocks, and when
you try to read one, you'll get an error back. Drivers try a few times,
and then give up, giving an error back to the user program.
You should not try anything different.
Now moving over to how software deals with this, essentially all DEC
OSes have some way or other to mark the known bad sectors as bad when
the filesystem in created, and then no software will try to use them.
I have some rough idea on how this is done in RT-11 and RSTS/E, but to
give details, I'll describe how RSX does it.
RSX have a program that scans disks for bad blocks. It is called BAD.
BAD will update the last track with any new bad blocks found.
A different program is used to create a file system on a disks - INI.
INI will read the last track of the device, to get the manufacturer and
user bad block list. INI will then create the file system on the disk,
and allocate all the bad blocks on the disk to a special file -
BADBLK.SYS. That way, those blocks are already marked as used, and other
files created cannot accidentally include those bad blocks.
Copying RL disks with a block by block copy is not something you'd do.
You'd mount the disk and copy the contents.
So, all disk blocks are numbered just as you would expect. Bad blocks
are not hidden, or mapped away, or returns zeroes. Doing anything like
that will break existing software.
Johnny
On 2015-04-07 00:54, Christopher Parish wrote:
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). Of course, this is only true for RL02K-EF (error-free)
packs. The common RL02K-DC packs (those with identified bad blocks from the factory) are
another story.
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.
Skipping the sector is a bad idea because the logical address of all sectors after it
will shift down by one. This will make the disk image not work correctly with SIMH, or
anything else for that matter, because most filesystems address things by physical block
(Please correct me if I'm wrong here). Remember, we're at the device level
(/dev/sda) not the partition level (/dev/sda1).
Returning all zeros for bad sectors will preserve the block numbers of following sectors
and work correctly with SIMH, but trying to restore the resulting image to another
physical pack will probably be impossible given the destination disk pack has bad sectors
of its own in different spots.
The usual trick of having the controller re-map the bad sectors will not work because the
platters in the RL02 are removable. Writing some mapping index on the disk pack or holding
back sectors in reserve will break compatibility with the original systems
(PDP8s/11s/VAXes) and all their software (an unacceptable solution).
I think I've come to the following conclusions given the restrictions above:
- Creating and Restoring images with EF packs is unrestricted
- SIMH operation with EF packs (online and images) will work perfectly
- Creating images of DC packs will work with SIMH if I return zeros for the bad blocks
- Online use of DC packs work with SIMH assuming no new bad blocks have formed since the
bad block index was written
- If new bad blocks have formed in a pack, SIMH will have to be modified so its RL(V)11
can receive error information from the drive, otherwise it will incorrectly handle the
recovery
- Restoring images on DC packs will require special software that can move data around
the bad-blocks (or a linux RT-11 filesystem driver *wink*)
- Using a modern filesystem on EF/DC packs is unrestricted (because they can identify and
manage bad blocks on their own)
First, does all of this seem reasonable?
I vaguely remember reading about a program on RT-11 you would run (before?) backing up
the filesystem. What was this program? How did it work? Did it make the data position
independent?
Christopher
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol