[Cryptography] LUKS on ATA versus on SSD

[Steven M. Bellovin]

On 1 Jan 2026, at 22:18, John Levine wrote:

>
> Oh, it was way messier than that. On IBM 360 mainframes, the physical structure
> of the disk was visible to application programs. Each disk had a fixed number of
> cylinders and tracks. (A cylinder was the set of corresponding tracks on each
> surface, since switching from one track to another within a cylinder was
> electronic, while moving from one cylinder to another meant physically moving
> the disk heads.) A file, which they called a dataset, was allocated a set of
> cylinders if it was big, or tracks if it was small. Each track was formatted
> with records which could be of arbitrary size, set up when a dataset was
> created.
>
> The disks were run via channels, specialized computers that managed I/O. A
> channel program would have a command to seek the heads to the desired cylinder
> and select the track, then a loop looking for the desired record (they were
> numbered on each track), then read or write the record. Application programs
> provided their own channel programs, which they told the operating system to
> run, after it used channel features that limited the user program to the
> assigned cylinder or track. Usually the channel programs were written by I/O
> libraries, called access methods, but it was not uncommon for applications like
> databases to write their own to get high performance or use quirks of the disk
> hardware.
>

Oh, the memories this brings back—and not always good ones… Channel programs could
contain branches. You could also could also request interrupts at any point in the
channel program, so you knew where things were, and perhaps modify the channel
program on the fly, though if I recall correctly you needed a nucleus (IBM's word
for what we now call a kernel) module to field such interrupts. One thing that a
channel program could do was to disable seeks to a different cylinder or even track—
the nucleus would do that, to restrict your program to the proper area of the disk
before branching to your channel program.

Two slight demurrers to what you said. The unit of allocation of datasets wasn't
so much dependent on the size as what the programmer wanted, often based on the
disk characteristics. For example, on a 2314 disk which had 20 tracks per cylinder,
you could ask for allocation as one cylinder or 20 tracks, and you'd get the same
amount of space—but if you asked for a cylinder, you'd get all 20 tracks in that
cylinder, avoiding any seek time within your dataset. (Yes, you had to specify the
size in advance, though you could specify secondary allocations to allow the dataset
to expand past the initial allocation, again in cylinders or tracks.)

I don't think that the dataset was formatted for blocks at allocation time, as opposed
to when you reached that cylinder, but you certainly had to specify the logical record
size and physical block size when the file was created. (And I thought that spares were
by cylinder, not tracks within a cylinder.) But I could be wrong; it's been many decades
since I did OS/360 systems programming.

IBM did introduce disks with logical block addressing around 1980.

Aside: back in grad school, I wrote a piece for the student newsletter called _The
Programming Languages of Middle Earth_. If you're an LotR fan like me, you may remember
that in Moria, Gandalf said that he "had to speak a word of Command". I asserted that
IBM's Job Control Language was "Command". Fred Brooks, the department chair and the
one-time head of the project that developed OS/360 when at IBM, disagreed: he felt that
JCL was the language of Mordor…


        --Steve Bellovin, https://www.cs.columbia.edu/~smb