RL02-USB Controller Status/Problem

[Johnny Billquist]

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