On Wed, Apr 25, 2018 at 10:02 AM, Tom Ivar Helbekkmo via TUHS <tuhs@minnie.tuhs.org> wrote:
Ron Natalie <ron@ronnatalie.com> writes:

> RK05’s were 4872 blocks.  Don’t know why that number has stuck with
> me, too many invocations of mkfs I guess.  Oddly, DEC software for
> some reason never used the last 72 blocks.

I guess that's because they implemented DEC Standard 144, known as
bad144 in BSD Unix.  It's a system of remapping bad sectors to spares at
the end of the disk.  I had fun implementing that for the wd (ST506)
disk driver in NetBSD, once upon a time...
​Right - back in the day, certainly for RK05's we would purchase 'perfect' media, because the original Unix implementations did not handled bad blocks.   You had to be careful, but you could purchase perfect RP06 disk packs from one or two vendors.  That got harder to do as the disks got larger i.e. the RMxx series.

A disk pack pack typically shipped with either a physical piece of paper or a sticker attached to them with the HD/CLY bit offset and/or if pre-formatted HD/CLY/SEC of an bad spots (int he old days disks used different formats depending on the controller and different sector sizes, meta data etc, so the bad spots were listed a bit position per ring).

A typical thing that a number of us did if we did not have a perfect pack was, after we did the Unix mkfs, manually create a file in either root, or lost+found called bad_blocks, and then using fsdb or the like, assign the blocks that file.   

The problem was the concept of 'grown' bad spots.   I'll stay away from the argument if they were possible or not (long story), but if in practice a pack ended up with a block that was causing issues after it was deployed (which did happen in practice).   You needed to assign the bad block to the bad_block file manual.

BAD144 was a scheme DEC had to reserve a few blocks and then map out any bad sectors.   The problem of course, was that it screwed up all the prediction SW in the OS, as system would ask for block/cyl/sec - X/Y/Z and it could force a head seek to the of the drive to get one of those reserved blocks in the end of the disk.   The advantage of the DEC scheme was the during formatting the known bad sectors would become 'invisible' and of course if the pack 'grew' and error the driver could add it to the list and replace the block on the fly (assuming there were available blocks in the reserved table).

An interesting story on BAD144 - a good example of the original ideas of Open Source.  It was actually the DEC 'Telephone Industries Group" in Merrimack, NH (a.k.a. TIG) that had Armando, Fred Canter et. al. that wrote the original support for DEC Standard 144; to help support the AT&T customers, pre Ultrix (remember for a long time AT&T was DEC'S largest customer).  Once written, that code was also given to CRSG and released into the wild via the UCB stream (and of course would become part of Ultrix when DEC finally 'supported' UNIX officially).

I've long ago forgotten, but aps might remember, I think is Fred that did the original work.