[TUHS] Re: Question about BSD disklabel history

Below... apologies if I forgot something -- this is pretty much as I knew it/play it out. On Sun, Dec 31, 2023 at 12:31 PM Grant Taylor via TUHS <tuhs(a)tuhs.org> wrote: Step one was the introduction of DEC RP04 disks -- 19 Heads, 21 Sectors/Track, 411 cylinders or 163989 blocks which will overflow a 16-bit PDP-11 register. You find it in the V5 code, but I have Dennis's rp.c driver showing split the RP04 into from v6: struct { char *nblocks; int cyloff; } rp_sizes[] { 40600, 0, /* cyl 0 thru 202 */ 40600, 203, /* cyl 203 thru 405 */ 9200, 0, /* cyl 0 thru 45 */ 9200, 360, /* cyl 360 thru 405 */ -1, 0, /* cyl 0 thru 327 */ -1, 78, /* cyl 78 thru 405 */ 15600, 0, /* cyl 0 thru 77 */ 15600, 328, /* cyl 328 thru 405 */ }; (V5/V6 C does not have an unsigned or longs; char * is how the compiler created a type that was treated as an unsigned 16-bit integer). If you look at things like the rk05 in V6, we reserve a few blocks at the end of the disk for swap. Remember quotas and file single file management are not there yet, so the scheme with the RP04 starts to be the way of the world. Also, remember Ted has not introduced what would later be called fsck(1), so recovery from a crash was painful. The corruption was often on the root disk, a quick dd(1) of the root FS you were quickly back - or at least bookable and then you could use check, ncheck, *et al *on the other partitions. Also, with PWB - a new set of tools was created for disk management that Research did not pick up: volcopy, cpio, et al. The V6 version of PWB is where *disklabels are first added to the superblock* BTW. In fact, when we did the original fsck(8) at CMU, we had v5 then v6. No, PWB pollution into our IP stream. So the original fsck I recently recovered for V6 does not have the disklabel code in it. When Ted goes to USG later, he adds the label support (which is why if you compile the version in the V7 addenda, it will get errors -- that one is the version on UNIX/TS - which the kernel supported disklabels). I had to look at the code, I think labels are simple, just names not information about that specific FS. The labels are not per disk pack. Meanwhile back in Murray Hill .... With V7, we have long int, but the partition scheme is already in use and has some nice side effects, so it is now a feature, and with the RP06 -- so Dennis's new scheme: struct size { daddr_t nblocks; int cyloff; } hp_sizes[8] = { 9614, 0, /* cyl 0 thru 22 */ 8778, 23, /* cyl 23 thru 43 */ 0, 0, 0, 0, 161348, 44, /* cyl 44 thru 429 */ 160930, 430, /* cyl 430 thru 814 */ 153406, 44, /* cyl 44 thru 410 (rp04, rp05) */ 322278, 44, /* cyl 44 thru 814 (rp06) */ }; At this point, as Arnold said, people would change the size/shape of the tables locally by recompiling and setting up the disk they way you wanted. It could be awkward, you typically needed a second disk pack, *etc*. With DEC's release of V7m, 2.x (2.1, I think), Fred Cantor of DEC put the first versions of labels into what would later become Ultrix-11. That code was released to CRSG (it is also where 2.9 et al. get Fred's wonderful swapping support). Shannon (still at DEC) helped Sam add some of that into a 4.1a/b/c stream... This was where Sam added things like newfs(8) and /etc/disktab and started to try to make BSD more resilient to different types of disks. But my memory is that it was nascent in the 4.2 release, so you had /etc/disktab and some of the tools but not everything until later, 4.3, when what you know today came into being. Meanwhile, in Pittsburgh ... CMU is working on the Mach2.5 project. Intel had donated some of the original 386 PC support to Rasid's group (they were partial funding) that they had developed with ISC/AT&T *et al* to handle things particular to the PC architecture -- such as the PC's fdisk(1) since PC's have a completely different way of partitioning things. Bob Baron did the Mach version - as to what was new and what was from Intel I'm not 100% sure. But CMU did have the tools that Intel felt they owned and were not part of System III/V. The key is that a PC's fdisk(1) - creates a UNIX partition within the DOS partition table so DOS knows to leave it alone, but then Unix sub-partitions using its own scheme. My memory here is hazy, I think the sub-partition code Bob used is different from the ATT's 386 [which most people saw as ISC's 386/ix who did the original work under contract for AT&T] Meanwhile, across the pond ... Andy's team starts to want a V7 for the PC/XT and starts the Minux project. I know they had CMU's Mach 2.5 stuff and there fdisk, while it seems to be independent (i.e. clean room) is very similar to Bob Baron's scheme. Meanwhile, in Walnut Creek ... Jolitiz *et al.* started 386BSD, which would begat FreeBSD/NetBSD/OpenBSD. At some point, Baron's fdisk (1) and support tools make their way to that project. This was why all the original UNIX for a PC used the same PC fdisk "type" ID number (the ISC 386/ix type -- from the original 386 port). [Linus built his own tools, which I think started from the Minux tools, and thus he did his own thing --- so Linux disks were not marked with the same types). If you look at the sources to both Mach and early 386BSD, you'll see Intel markings as well as Bob's name in a couple of places [Truth in advertising here (different story) -- I wrote most of the original AT disk driver Bill used -- I was consulting for NCR and had access to the WD specs as well as the CMU code but I was not the conduit of the CMU code base to Bill]. At some point, 386BSD started to go one way, and what would become FreeBSD started to ramp up. Jordan Hubbard wants an "easy install" like Microsoft has for Win98, so very early FreeBSD has the first PC-based install that can run without much intervention. At some point, Jordon or someone else in the FreeBSD team introduced what they called slices, furthering the BSD scheme but designed to overlay the PC better. The NetBSD folks had already split off, so they did not pick it up. When OpenBSD split from NetBSD, they did something similar but different to FreeBSD's slices... Meanwhile, in Cupertino .... Next (ney Apple) started with the Mach code base from CMU. There was a push in the Valley in those days for something called OpenFirmware [Warner help here -- I think that it was forth based IIRC, and Sun may have had their hand in it also]. But the key is that it ran on 68K's. So Next's original partition scheme was influenced if not based on some of Bob's work, although they did not need the silly BIOS stuff, so they did make it all talk to OpenFW (BTW: I think that was still all Next) By the time the Intel Mac's BIOS had begun to be replaced in the WINTEL world by UEFI, Apple committed to using a flavor of it. My old lab partner, Guy Sotomayer (*a.k.a.* gss on many mailing lists) was mixed up during his time at Apple. He might be able to fill in some details if I ask him. I also know that Apple was not happy with how disks were handled with the original partition scheme, and by later release started over with their partitioning scheme(s) at least once. I've undoubtedly left stuff out, such as much of Linux - but this is all part of the UNIX war I was a player.