[TUHS] Question about BSD disklabel history

Warner Losh imp at bsdimp.com
Mon Jan 1 06:07:41 AEST 2024


On Sun, Dec 31, 2023 at 10:39 AM <arnold at skeeve.com> wrote:

> The different overlapping partitions predates disk labels.
> Up to and including 4.3 BSD, to change the size of partitions
> on a particular disk, you had to recompile the kernel.
>

Yes. Disk partitions were implemented in the disk driver dating back
at least to the 5th edition. Lack of sources makes it harder to know
for sure. The man pages for each of the disk drivers included the
partition layout (IIRC, I didn't cross verify).


> They were that way so that if you had multiple disks, you
> could use one for root + swap + some thing small and use another
> whole disk for a single filesystem.
>

Yes. Unlike today, the partitions covered the disk in different, overlapping
ways. And allowed for some parts of the disk to be uncovered by a
partition. You could then patch the offset and length into the kernel with
adb and use that area of the disk for swap space.


> It was also helpful, if you had the drives, to nightly dd
> your real root to the "a" partition on another, identical
> drive, so that you could boot the backup root in an emergency.
>
> I don't remember for sure, but I think that Ultrix may have
> been the first BSD-style system to have disk labels, followed
> by some version of SunOS. All of that is way in the distant
> past though: mid- to late 80's.
>

When I looked into it years ago, I convinced myself that SunOS
was the first to have it (since the very first version of SunOS 1.0
had disk labels) and that all the other vendors followed suit within
a couple of years. Ultrix-11 had the fixed labels through its EOL.
I didn't see any disklable stuff in the Ultrix-32M that we have, but
it was admittedly a quick look.


> I am guessing that the original conventions date back to
> V7 or 32V, but one would have to go looking at code to be sure.
>

Yes. The conventions are as old as Unix. And did change at least
between V5 and V6 and I think maybe again for some drivers between
V6 and V7 (though I'm less sure of this).

BSD4.3 Tahoe, the first release after BSD4.3, fixed the disklabel format.
Sun's vtoc format (aka sunlabel) was different from that, but quite
similar. This is why it's called 4.3BSD format in many places, even though
it wasn't in the original 4.3BSD release.

OpenBSD and FreeBSD's disklabels are the same format. However, OpenBSD's
have twice as many entries than FreeBSD's. And there's a number of other
fussy
details about what different labels mean based on the shared history and
divergent
evolution of the two systems. OpenBSD also supports both endians, while
FreeBSD
only supports native endian. So these changes and different decisions lead
to
the situation today where it's hard to read them on each-other's systems.
Plus with
the new, larger disks FreeBSD has effectively abandoned them in lue of GPT
partitioning.
There is a disklabel64 format too, but I'm unsure how widely that's
deployed.

All the commercial Unixes also had their own format. AIX, HPUX, DG, etc.
That's
a topic for another time...

Warner


> Grant Taylor via TUHS <tuhs at tuhs.org> wrote:
>
> > Hi,
> >
> > I've found myself wondering about partitions inside of BSD disk labels.
> >
> > Specifically, when and where was the convention that "a" is root, "b" is
> > swap, etc?
> >
> > I also understand the "c" partition to be the entire disk, unless it
> > isn't, at which point it's the entire slice (BIOS / MBR partition)
> > containing the BSD disklabel and "d" is the entire disk.
> >
> > I also found something last night that indicated that OpenBSD uses disk
> > labels somewhat differently than FreeBSD.
> >
> > Aside:  This is one of the dangers of wondering how something curious
> > came to be and why it came to be when working on 10-15 year old FreeBSD
> > systems.
> >
> >
> >
> > --
> > Grant. . . .
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20231231/14bd4522/attachment.htm>


More information about the TUHS mailing list