The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Warner Losh <imp@bsdimp.com>
To: arnold@skeeve.com
Cc: tuhs@tuhs.org, gtaylor@tnetconsulting.net
Subject: [TUHS] Re: Question about BSD disklabel history
Date: Sun, 31 Dec 2023 13:07:41 -0700	[thread overview]
Message-ID: <CANCZdfrGThzgP=QjrS-cuxj5knRg0LGe+M7H801wJAtRSwt2xA@mail.gmail.com> (raw)
In-Reply-To: <202312311738.3BVHctA1018336@freefriends.org>

[-- Attachment #1: Type: text/plain, Size: 3924 bytes --]

On Sun, Dec 31, 2023 at 10:39 AM <arnold@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@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. . . .
>

[-- Attachment #2: Type: text/html, Size: 5514 bytes --]

  reply	other threads:[~2023-12-31 20:08 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-31 17:30 [TUHS] " Grant Taylor via TUHS
2023-12-31 17:38 ` [TUHS] " arnold
2023-12-31 20:07   ` Warner Losh [this message]
2024-01-01  0:13     ` Bakul Shah
2023-12-31 20:27   ` Phil Budne
2023-12-31 21:02     ` Warner Losh
2024-01-01  0:26   ` Grant Taylor via TUHS
2024-01-01  2:22     ` Warner Losh
2024-01-01  3:24       ` Grant Taylor via TUHS
2023-12-31 21:31 ` Clem Cole
2023-12-31 22:07   ` Warner Losh
2024-01-01 16:00     ` Clem Cole
2024-01-02 18:49       ` Warner Losh
2024-01-02 19:30         ` Chet Ramey
2024-01-02 20:07           ` Clem Cole
2024-01-02 19:50         ` Dan Cross
2024-01-02 19:55           ` Jim Capp
2024-01-02 20:11             ` Dan Cross
2024-01-02 20:30           ` Dan Cross
2024-01-02 20:50             ` Clem Cole
2024-01-02 21:04               ` Dan Cross
2023-12-31 22:46   ` G. Branden Robinson
2023-12-31 23:06     ` Larry McVoy
2023-12-31 23:37       ` Al Kossow
2023-12-31 23:41       ` Alec Muffett
2024-01-02 20:48       ` Dan Cross
2024-01-02 21:17         ` John Cowan
2024-01-03  3:33         ` Theodore Ts'o
2024-01-03  3:57           ` Warner Losh
2024-01-03  4:03             ` Warner Losh
2024-01-03  4:30             ` Theodore Ts'o
2024-01-03  5:10               ` Warner Losh
2024-01-03 15:56                 ` Dan Cross
2024-01-03 16:37                   ` Theodore Ts'o
2024-01-03 16:41                     ` Dan Cross
2024-01-04  8:42                     ` arnold
2024-01-04 18:26                       ` Kevin Bowling
2024-01-03 14:39           ` Dan Cross
2023-12-31 23:08     ` Phil Budne
2023-12-31 23:37       ` G. Branden Robinson
2023-12-31 23:59         ` Warner Losh
2023-12-31 23:50     ` G. Branden Robinson
2024-01-01  0:09       ` Al Kossow
2023-12-31 21:55 Norman Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANCZdfrGThzgP=QjrS-cuxj5knRg0LGe+M7H801wJAtRSwt2xA@mail.gmail.com' \
    --to=imp@bsdimp.com \
    --cc=arnold@skeeve.com \
    --cc=gtaylor@tnetconsulting.net \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).