Hacker News new | past | comments | ask | show | jobs | submit login

Check out IBM's mainframe Count key data (CKD) format:

https://en.wikipedia.org/wiki/Count_key_data

There were no sectors, just data fields. Also each data field had a text key field. I think IBM only gave this up (really virtualized it) when commodity hardware became better than their own.

So I'm wondering if CKD was ever a thing on floppies?




> There were no sectors, just data fields

That's not really true – an (E)CKD record is fundamentally the same thing as a sector. The difference is that on standard hard disks (what in IBM nomenclature is called FBA DASD), the norm is every sector on the disk has the same size; CKD permits each track to have a different sector size, and even different sized sectors on the same track. Also, CKD optionally has separate key and data fields, with a physical gap between them; in floppies and standard hard disks, there is only count and data fields (count = sector header), and any key-data separation has to be marked logically (by a byte offset) not physically.

> So I'm wondering if CKD was ever a thing on floppies?

No, CKD was never used for floppies. In the standard IBM floppy format, the sector size is in the header of each sector, so in principle you could have a mix of different sized sectors on the same track, like CKD permits; in practice, I've never heard of anyone doing that, I question whether the floppy disk controller could cope with it; even if the FDC somehow could, almost all software would be confused by it. (I suppose if the FDC can handle it, someone may have adopted it as part of a floppy disk copy protection scheme.)

Something which did actually happen, albeit rarely, was formatting the first track on the disk as 128 byte sectors, and the remaining tracks with bigger sectors (such as 256 or 512 byte), to retain some limited backward compatibility with older systems that only supported 128 byte sectors; at least being able to read the first track might make clear it was a valid disk that just couldn't be read on this system, as opposed to thinking it was an invalid disk, and then formatting it in response, causing the loss of that valid data. Systems that did this sometimes also physically recorded that first track as FM, while using MFM for the remaining tracks. This was largely a 1970s concern; by the time the 1980s came around, systems which only supported 128 byte sectors had become practically irrelevant.

The classic IBM 3740 floppy filesystem supports record-oriented files. Some vendors other than IBM adopted it (e.g. Olivetti), but most non-IBM vendors ignored it, and developed their own filesystems instead (e.g. the CP/M filesystem, Microsoft's FAT). ECMA standardised an ASCII version of it as ECMA-91 in 1984 [0]. That standard didn't support keyed/indexed files, but could easily have been extended to support it–if anybody had cared to do so, as I said, relatively few vendors ever paid attention to it. The 3740 did support a key field in each database record (sector), but the key-data separation was only marked logically (by a byte offset into the data), not physically by a recording gap.

[0] https://www.ecma-international.org/wp-content/uploads/ECMA-9...


>in principle you could have a mix of different sized sectors on the same track, like CKD permits; in practice, I've never heard of anyone doing that, I question whether the floppy disk controller could cope with it

That was actually done by IBM to distribute some versions of OS/2 2.x (or was it a later one?). It was called XDF and was originally invented by a company making backup-to-floppy software. And of course it needed a special driver to access: IIRC the one built into OS/2 was also read-only, and the first few installation floppies were in standard format so that you could boot from them.

The PC floppy controller itself has no problem reading or writing different-sized sectors, provided you didn't try to do multiple ones in a single command.

But creating the low-level format with PC hardware required a crazy hack: fill the track with 128-byte sectors without any gap between, but setting up the "C,H,R,N" header fields for larger sectors with the correct spacing. The remaining dummy sectors would then become part of the larger sectors' data and gap field, so their headers didn't matter (and would be overwritten when writing the actual data).


Oh yes, you are right, I'd forgotten about XDF.

Although there is still a big difference between floppies and CKD hard disks – on IBM standard floppies, the sector size has to be a power of 2, minimum 128; on CKD hard disks, the sector size can be anything – 80 byte sectors, 300 byte sectors, whatever one wishes. On z/OS, several file formats require a 3120 byte block (=sector) size. Under CMS, the standard sector size is 800 bytes.

Hard disks (as opposed to floppies) commonly support non-power of 2 sector sizes, of 520 bytes or 528 bytes – for RAID systems which need to store additional metadata with each 512 byte sector. And with newer 4096 byte sector support, one sometimes finds support for 4104, 4160, and 4224 byte sectors. But, that's still not like CKD, in that most hard disks only support a fixed set of sector sizes (512 or 4096 base size plus some bytes of per-sector metadata), not arbitrary sector sizes like CKD does.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: