7

The Wikipedia article History of IBM magnetic disk drives describes the details of the IBM 2311 device, introduced in 1964, as

The 2311 stores 7.25 megabytes on a single removable IBM 1316 disk pack. ... Each recording surface has 200 tracks plus three optional tracks which can be used as alternatives in case faulty tracks are discovered.

What was the intended usage model of the extra tracks as alternatives to the faulty tracks? Specifically, how was remapping supposed to work: at the drive level, or at the controller/IOP level, or at the OS level?

Were the last three tracks special in any way? What does "optional" mean in the context?

5
  • 2
    No time. Controlled by host side software. Optional means simply in case needed.
    – Raffzahn
    Mar 11, 2022 at 17:52
  • 1
    @Raffzahn So the software was free to use all 203 cylinders as desired? In other words, instead of advertising the pack capacity as 7.35 Mb and incurring complaints about the media quality, IBM simply did some sandbagging? No hardware support for automatic track remapping anywhere?
    – Leo B.
    Mar 11, 2022 at 18:01
  • @LeoB.: If some means existed to patch the OS, it would have been fairly simple and cheap for it include some code "if track > 200 track++; if (track > 200) track++; if (track > 200) track++;", and then be prepared to have technicians patch the OS if the need arose. Such means wouldn't be "automatic" in the modern sense, but would make it possible to "repair" a drive if a defective track were discovered.
    – supercat
    Mar 11, 2022 at 20:28
  • 1
    @LeoB. Yes and no. Reading/writing of a formatted disk is done transparent by the 2841 SBU. All initialisation and assignment during formatting is done by host software. Yes, in theory software creating it's own format could use all 203 cylinders. But the /360 series wasn't meant for one off designs created by hackers in some laboratories, but industrial IT. Here it's way more important to rely on having all disks providing a defined amount of space. In production there is no time to find the one fitting the task. Better leave 1.5% unused as have a single failing job.
    – Raffzahn
    Mar 15, 2022 at 22:09
  • 1.5% redundancy/safety overhead/sandbagging sounds ridiculously low for anything near even the word "production". Jun 10, 2022 at 4:57

3 Answers 3

8

TL;DR:

No, these were normal cylinders and tracks. They were simply reserved to hold alternate tracks. They were assigned during formatting by control of the OS (or better the formatting utility). Reason was to guarantee that every (successful formatted) drive always contains 2000 usable tracks.

During normal operation of a formatted disk the replacement process is handled by the microprogrammed 2841 SBU in real time. Formatting and Initialisation of a disk is entirely defined by host software.


CKD and other oddities

Understanding the details about how DASD drives in general and the 2841 SCU (Storage Control Unit) with its IBM 2311 DSD (Disk Storage Drive) (*1)in particular work requires taking a step back and forget about today's canon of tracks and sectors. Best way to imagine it is a cluster of 2000 tape drives plus 30 spare drive, each having a short tape mounted. On a primitive level each of these 'tapes' is a single file.

Weird, isn't it?

Today we're only looking at disks with almost fixed structure or solid state drives with fixed structure. But IBM's DSAD design was intended to unify such different storage devices as

The only common feature here is really a track, so a track is what was managed on device and controller level. The resulting idea was variable length, high level data format called Count Key Data.

But lets first look at the hardware:

The 2311 Drive

They physical 2311 drive is an improved 1311. The roughly 5-fold in capacity was gained by halving track width (doubling the number of cylinders from 100 to 200) and increasing the write clock, which brought the storage up from ~1.5 Million Bytes (8-bit) to more than 7. All while using the same IBM 1316 Disk Pack (*2)

The 2841 Controller

The 2841 was a stand alone unit able to control up to eight drives and two host channels, allowing either redundant operation on a single host or concurrent use by two mainframes. It was itself a mico-programmed unit, able to handle rather high level tasks, like searching for a certain record or even index key, relieving the host by reducing otherwise complex operations to very basic I/O commands. The 2841 is the original base for DASD with CKD storage.

Count Key Data (CKD)

Count Key Data was IBM's answer to unify three very different methods of data storage (Disk, Drum, Cells) into a single interface, while at the same time offloading basic tasks to hardware.

To understand this it's helpful to keep in mind that disks where incredible fast compared to what a CPU could do. At the same time, data transfer did put much load on memory, as data needed temporary storage to be searched. The solution to this was to enabling search while reading out on the disk. All controlled by the way channel command could be chained to form a meta program. Detail (*3) are past the topic of this question so let's focus on the track replacement part. This is based on the format structure of a track. A structure independent of it's media, present on all three types of drives.

CKD Structure

The name CKD is simply the sequence of blocks that build a record within a track (file), a Count Area (block), an optional Key Area and a Data Area. So let's look inside a Track.

A Track consists of

  • an Index Point, marking the start of a track
  • a Gap and
  • and Track Data

Track Data in turn is build from

  • the Home Address
  • a Track Descriptor Record (R0)
  • and zero or more Data Records (R1..Rn)

The Home Address is where all starts. It holds

  • a Flag Byte holding only two bits noting
    • Track being operational or not
    • Track being the original one or an alternative (reassigned) one
  • its address, noted as
    • Cylinder
    • Head (*4)
  • and a CRC

For further understanding it's important to note that the home address could only be written by a special, dedicated I/O command word, usually only issued by the formatting utility (or real tricky user software :)). Thus the decision if a track is original or alternate always comes from the mainframe software, not the 2841 controller.

The home address is followed (*5) by the Records stored in this track. Each record consists of

  • a Count Area (block)
  • an optional Key Area
  • a Data Area

For the track replacement magic only the very first record, R0 or Track Description Record, is relevant and thereof only content of the Count Area, thus I'll spare going into further details past this.

The Count Area is an 11 byte field with various markings and information containing

  • a Flag Byte which is a copy of the flag byte of the Home Address.
  • a repetition of the track address as
    • Cylinder
    • Head
  • a Record Number of '00' identifying the record as R0,
  • length of a following Key Area (0..255),
  • length of a following Data Area (0..64 Ki),
  • and a CRC

The host view of this is an 8 byte field as the Flag Byte and CRC are only visible to the 2841. The flag byte is a direct copy taken from the Home Address, while CRC is calculated (and checked) local.

We'll spare the remaining records, as all replacement happens on the level of Home Address and the Count Area of R0.

Replacement Indication

Interesting for track replacement is the copied Flag Byte and the Track Address. Tracks that got replace are marked by a bit. When set, the track address contains the location of the spare track to be used.

Replacement Interpretation

When the 2841 executes a seek command to position at a certain track, it checks the Home Address to verify positioning (*6). If correct, it checks the Flag Byte if the track has been relocated. If yes, it continues to read the R0 record, extracts cylinder and head and restarts positioning to the new address.

Here the position will be again checked against the Home Address, holding the 'real' track number. In contrast, all following records, including R0, will hold the Track Address of the original track. I.E. except for the Home address, and the repeated Flag byte, all track content, including addresses will look exactly like it would be without being relocated.

This makes the relocation essentially invisible to all host (normal) host software. It can only be detected by issuing a dedicated _Read Home Address command (*7).

Replacement Initialisation

While the interpretation of reassignment is done by the 2841 SCU, invisible to all host software, its instalment is done purely by host software. When a defective track is detected during formatting, a replacement track is selected and checked for not being defective.

If one is found to be usable, it's written with its genuine Home Address but with a Flag Byte marking it as a replacement track and an R0 record holding the track address. Only if this is successful the replaced track is (re)written with a Flag Byte noting it as replaced and a R0 record with the address of the assigned replacement track is written.

If

  • the replacement track can not be formatted, and
  • no further replacement track is available (all used up), or
  • the original track can not be overwritten with the needed redirection,

then the whole disk will be rejected.

All of this is done under direct host software control. The SBU does neither interfere nor act on its own.


BUT WHY?

There are eventually two questions:

Why Fixed to 200 Cylinders?

Why not using all 203 for storage and just mark defective tracks. After all, in most cases it would make a bit more space available, as rarely all 30 reserve tracks are needed. In addition even 'lower' quality disk would be still usable, wouldn't they?

The answer may be manyfold:

First of all, it's important to keep in mind that the system /360 is designed to replace all prior IBM equipment. This includes foremost all accounting machinery, as that's were the money was - and still is. In production nothing is more important than reliability. NOTHING. Guaranteeing that there are always 2000 tracks available does straighten provision planing.

Second, and that's equally important, those machines were slow in comparison with disk drives (*8) and memory was scarce. Any architecture that can avoid reading intermediate data before reading the needed ones will speed up execution more than anything else. There is no room for highly abstract systems that do need much management which leads directly to the third point here:

Last there is low level user access. These machines had to run with no or just minimal OS layers. There was neither room (memory) nor power (CPU speed) to handle what we know today(*9). Application software had to be as close to hardware as possible, which meant in turn the functions we see today as software had to be done in hardware (*10)

Still, Why Not Sectors?

Beside the fact that it wasn't a sector based file system? Beside the fact, that the file system offered high level function like indexed search (modern buzzword: relational access, associative memory) without any host software?

Well, there is still performance and resources. Remapping single sectors across a disk slows down access a lot. In real world application, reads are seldom single sector random access, but more often sequential reads. Meaning that the sector before a faulty one, it's replacement and the following are likely read together. There are essentially two remapping strategies:

  1. Remapping into an overflow region

    Here every defective sector is replaced by one of an overflow region, maybe at the outer end. Whenever a defective sector is accessed, the head(s) need to be moved all across the disk to access it's replacement and move back again. I can't think of any way better to slow down disk access (*11).

    While track remapping also means moving to a new track, there is no need to move back - at least not for the whole content of that track.

  2. Using a virtual remapping

    Here a table of all sectors is kept, assigning logical sector numbers to physical and leaving out inaccessible in turn (*12). A great idea removing all need for head movement, just capacity between head movements gets reduced.

    It just carries two major drawbacks: It needs a fixed storage location there this table can be found by the controller (something the track method doesn't need) and, even more important, it needs a huge amount of memory. One word per sector. If a 2311 would have been formatted with 2 KiB sectors, there would have been ~3700 sectors, thus a table of at 12 bits per entry to be held in controller memory. That's ~6 KiB of RAM per drive. That's 48 KiB for 8 drives. All to be stacked within the controller. At a time when 48 KiB was the maximum memory for a Model 30 (base memory was 16 KiB).

    Doing it within CPU Memory would slow execution further down and add another software layer, killing performance even further. Similar if that table is not kept in memory but read wehnever needed.

Long story short: What's canon today would bomb the business back then.


The Future (of 1965)

Of course, when the world turned toward fixed sized blocks and storage management based on such simple units, IBM did as well and CKD became for many applications turned in a system much like we know from smaller systems, one based on Cylinder, Head and Sector instead of Track and Record. Already in the 1970s, for many applications, data block and key block turned into a fixed length units, making it work mostly like known in other places, virtualizing parts of the original structure.

By 1980 IBM introduced Fixed-Block Architecture as well on user level with the introduction of 3310/3370 drives.

While DSAD is still integral part for next to everything in zOS, features became emulated on top of fixed size disk structures. By now all (new) disk devices on IBM mainframes are sectorized with the header noting an address and single fixed size data block following.


*1 - For this topic the /360 Model 25 integrated Disk Attachment Control (DAC) can be ignored, as it did for most parts emulate what a channel controller and a 2841 SCU did for the larger models.

*2 - As others have pointed out, this hardware has been used by many other manufacturers (like DEC). After all, the 2311 was the first IBM drive used over a wide variety of machines, making it a prime target for plug compatible manufacturers. But that's only the drive. Format and capacity did vary between different companies.

The 2311 is what made CDC a big name in business. While we now remember CDC mostly for their Cyber machines, building IBM compatible drives, tapes and printers was what brought in the money to fund all their computer development.

*3 - If you thought modern Command Queuing is a marvel, think again, this was already standard for mainframes 55+ years ago. Even better, modern NCQ isn't much past buffering and asynchronous operations, while channel programs allowed to put steps into context and conditional about prior results - like seeking to a certain track, searching for a key, then searching for a sub key or a data item or ship a block and finally read and transfer a series of records, unconditional or according to further selection. All of this done by the controller in hardware and real time, so even complex search orders could be finished in a single disk rotation.

*4 - Both values as 16 Bit, so in theory 4 Gi or tracks could be managed on a single drive. IBM didn't try fall victim to premature saving :))

*5 - The 2841 does insert Gaps between home address and following records as well as between records. More gaps are between elements of a record (C,K,D) are (may be) inserted. Length and position depend on each device type. They are not part of the logical structure as seen by the host system.

*6 - In case of a mismatch the seek is repeated 3 times until a not found is reported.

*7 - Well one could always try to check timing and guess, but that's not really a method for serious operation.

*8 - In some way it's like a decade later with micro processors and main memory. Micro CPUs were so slow, that it (almost) didn't matter if an ISA featured almost no registers on chip (like a 6502), handling all data of chip or one having a comparable lot (like a Z80 or even 68k), able to hold core data on-chip. Effective speed was almost entirely related to memory bandwidth.

*9 - A bit like with the IBM-PC again - although I'd rather put that on too many hobbyist programmers going ahead with preliminary optimizion.

*10 - I always like the irony of time, as after eliminating all 'intelligent' hardware to employ as primitive as possible devices and move everything over to software, we now try very hard to outsource it again - applauding advancements that are still dwarfed by what was done 50+ years ago.

*11 - It can be reduced a bit by spreading out the spare sectors across the whole disk.

*12 - A bit like MS-DOS' FAT structure. Except that's a linked list holding the file sequence as well.

11
  • 1
    each having a short tape mounted Oh, it's a Mellotron ! :-)
    – dave
    Mar 15, 2022 at 22:28
  • @another-dave LOL. What a glorious insight. Yeah, a supersized Mellotron.
    – Raffzahn
    Mar 15, 2022 at 22:51
  • 1
    Thank you! From your description it is now clear to me that the BESM-6 disk controller, although homebrew, reproduced the logic of 2841 quite closely. Apart from a somewhat simpler structure of the Home Address, because there was only 1 "sector" per track, everything else is very similar. The formatting program, if it detected that a track does not hold data properly, first tried to see if the redirection information can be written on it, before even starting to pick a replacement track. It would attempt to write it up to 32 times with increasing gaps, then give up and reject the whole disk.
    – Leo B.
    Mar 15, 2022 at 23:44
  • 1
    @LeoB. Well, I did leave out that part about retrying to write Home Address and Count Area with different parameters to ensure that it somehow get still placed on defective tracks. Thought it would make the explanation even more complex. In fact, formatting utilities take care of a lot more rare cases to make a disk usable. Another reason whey they have been made as utility, not integrated within any OS.
    – Raffzahn
    Mar 16, 2022 at 0:01
  • 1
    @LeoB. :)) I see. The statement might need a bit more emphasis on the not integrated art. While all /360ff operating systems did have formatting utilities. "not integrated" here really means free of any OS relation. The basic format utility was self loading. It could be used from a bootable disk stack, boot from a tape or even a card stack. Thus it was possible to bring up a system complete from scratch without any OS, add disk drives and format them without ever loading an OS as we know it. The format utility did not carry a bundled minimum-OS. It was a 100% independent development.
    – Raffzahn
    Mar 16, 2022 at 0:14
4

Disks seldom have defective tracks: they normally have defective sectors. There were different schemes employed, depending on the disk controller and the OS.

Scheme 1 Using spare tracks. This didn't actually work on tracks: more on sectors. If a sector was defective, it would allocate a spare sector from the spare tracks. When that sector was addressed, the disk controller would jump to the spare sector on the spare track. Since the spare tracks were normally allocated at the end, there was a huge amount of head movement.

Scheme 2 Using extra sectors. Say a track had 22 sectors. The system would allocate 20 sectors and leave 2 spare. The theory is that if a defective sector was found, one of the two spares would be used in its place. This allowed up to 2 sectors to be defective. This was more efficient than scheme 1 in terms of head movement. This was inefficient in terms of space. If there were 500 tracks, there would be 1000 just in case something went wrong unused sectors.

On the early 3.5 inch disks defective sectors used to be printed on the label of the disk. With Scheme 2, one had to make sure that there weren't more than 2 defective sectors on one track.

4
  • 1
    Did any systems simply skip defective tracks while keeping everything else in order? I would think that would have the least impact on performance, while loosing much less disk space than reserving extra sectors per track.
    – supercat
    Mar 12, 2022 at 14:26
  • 1
    Are there examples of systems implementing these two schemes? And if the "controller" detected a bad sector, (a) did it attempt to save the existing content? and (b) where did it keep the remapping data?
    – dave
    Mar 12, 2022 at 22:25
  • I don't know of any systems that skipped defective tracks. In those days, when there is a defect, it is a patch on a disk affecting more than one track. From the defect information printed on the disk, you could work out which track and sector they were. Often it was different tracks on the same sector.
    – cup
    Mar 13, 2022 at 6:28
  • "Disks seldom have defective tracks: they normally have defective sectors." -- If this IBM 2311 is like SMD, then these disk drives predated the use of fixed-sized sectors. Each track was formatted with ID & data records. There was nothing to force you to format each track with identically-sized records or "sectors". It's ECC capability that constrains record/sector sizes. The 8" floppy used a similar scheme for its soft format.
    – sawdust
    Mar 14, 2022 at 4:59
2

Not IBM I'm afraid, but DEC's Files-11 On Disk Structure level 2 (ODS2) had to handle both manufacturer detected bad blocks and software detected bad blocks.

The manufacturer created a list on the highest track which had the serial number of the disk, some flags, zero or more bad block entries and finally a 32-bit longword FFFFFFFF to signal the end. Each entry on the list recorded just the track, sector and cylinder.

The software detected bad block list along with manufacturer's bad block list are stored in a file BADBLK.SYS. This is always the third entry in INDEXF.SYS which is the first file on the disk.

There is also a file BADLOG.SYS which records pending bad blocks, those that are suspect and have not yet failed.

The ACP or XQP will not allocate these bad blocks to a file, instead it revectors them to space in the spare tracks. The actual file layout is recorded in the map area of the file header as a series of pointers and run lengths. A file which would otherwise occupy a bad block is therefore simply a fragmented file.

The above is a slight simplification. Earlier disks (RK**, RP** and RM**) followed this, later disks (RA**) implemented the Digital Storage Architecture (DSA) whereby hardware and the low level DUDRIVER consipre together to maintain a Replacement and Caching Table (RCT) which funtionally replaces BADBLK.SYS.

Quoting the last paragraph of McCoy (1990) §2.5.3.1: "The rest of the sectors on the last track (sectors 10 to 21) contain the software bad block descriptor. These sectors have the same format as the manufacturer's bad block descriptor except that the area for bad block entries containes all 1s, which indicates that no bad sectors are listed. This area is where the system software may list the sectors that have become defective while in use."

Reference: McCoy, Kirby. VMS File System Internals. Bedford, Mass: Digital Press, 1990. 005.74.

5
  • 1
    I don't recall DEC disk packs having actual "spare" tracks though; you just avoided known-bad blocks. A new (removable) pack would have bad blocks written on a paper label as well as possibly recorded in the last track. Typically, depending on OS, you could manually tell the file system about those blocks (if the OS did not know to read the last-track badblock list), as well as/or running an extensive badblock check before initializing a file system. I would never install an OS on a new pack without that check.
    – dave
    Mar 12, 2022 at 18:36
  • 1
    One clarification - BADBLK.SYS isn't a list of bad blocks, it is the bad blocks. That is, the bad blocks are marked as allocated to the file using the same mechanism that any file gets blocks allocated to it. That of course means that no special action is needed to avoid allocating those blocks to any other file.
    – dave
    Mar 12, 2022 at 21:37
  • I stand corrected. Per gunkies, the RP01 was the equivalent to the IBM 2311 and had 203 tracks, 200 nominal + 3 spare. Similarly for RP02/RP03.
    – dave
    Mar 13, 2022 at 1:32
  • @another-dave Formatted disks with a file system structure had it easy; IBM with its "count key data" had a complex track marking mechanism. I don't quite understand at what level it worked.
    – Leo B.
    Mar 13, 2022 at 7:32
  • @LeoB. If you're interested in CKD, put up a question. But please don't expect any answer today :)) Beside, CKD is an extreme simple and straight forward design. really lovely and high performance. Just, today's readers must be willing to take a step back and think in advanced data structures - structures that allow 'streaming' execution by comparably simple hardware offering quite advanced performance :))
    – Raffzahn
    Mar 15, 2022 at 23:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .