From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13996 invoked from network); 31 Dec 2023 20:08:09 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 31 Dec 2023 20:08:09 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 447DD43DE2; Mon, 1 Jan 2024 06:08:03 +1000 (AEST) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by minnie.tuhs.org (Postfix) with ESMTPS id 9276E43DE1 for ; Mon, 1 Jan 2024 06:07:54 +1000 (AEST) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a236456fee1so935458366b.1 for ; Sun, 31 Dec 2023 12:07:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704053273; x=1704658073; darn=tuhs.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KZKyjShKcx4tUrz5O8p3uJkNMNGWQZwDoZcVhPkR3vE=; b=jDz4uWA8GmbCAQ5hDEFGPZ+4JO3urb7kCBXVaSwM9DWqrJ4zc2UtM8v6bp/AnEx9on VYBKOgWtUj3IchK4ZWtXMu+Xv5Ul/PmO6mId1CcRH+VgXNwbvwzzasSq2o4gem3b4UJd LlOUtrDKFC5E2PN+eys938CE3N3QYBI9mF5Dng902AsC/WPiqXK/0aprPTQnvi1MzS/O G649q/V+RjSw7MC3jpd6n7OVisPkpsi2wW8WYAfeY9L1lsez2fE9EiQV23bLr0wCJRPx nXBZS9051tYfBLpMybvtBVNMOPALo+pXtgOD9kuLszawgGCRyDUOTRw1zOX/3KzSHW1i V6BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704053273; x=1704658073; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KZKyjShKcx4tUrz5O8p3uJkNMNGWQZwDoZcVhPkR3vE=; b=FtxojWpzyFZKX7unESh2JN0GIGY/9d5Psx8/gJgdWs8Gv2n/eOPCJGZUtLdX7aRS/a a7rpVF0iXu0XgjM+62EAwIuEVYXQO3wVZk/Hd5QjTYxeVpnfd/Toy5RluaOLnSPsdlHy abHZTt/fYEgV6WBXSRgiKBfjjoRKyTai0ETeFzsOTYDSEl6cnzIFCcRJf6xne3leqiHr IwoH0+NUpBfRYlUXhsKa9dkWZhSOqIQw+uedHxunJXQV5PmM6ZtnLBubE6FbfApG5BqN yMKNNOxEkofVoyvxq5u7/E148fC5tL0wrYu2+CVHW8Eacr0P+mCqEKw+R81+bD2v43iz MQAQ== X-Gm-Message-State: AOJu0YxOrv91o91TU616xSi5h6rZdntiW76vm30vniWyF2aOEt0VHwmq +T4N8BlFlqlRVv+aqhc7qXgwpjGEiEeiz/bImZ6OvEFj0CfqRSdkuNenwPfYthg= X-Google-Smtp-Source: AGHT+IGTvMWcectuwBYZ6WePreYd+XSlbOM8WvbuDsLki5aMb81X0bj+ZfQOzi8rvmfU6N9EGqfYLY9cmbcxIURGKnA= X-Received: by 2002:a17:906:c104:b0:a27:ee22:6029 with SMTP id do4-20020a170906c10400b00a27ee226029mr653792ejc.66.1704053272779; Sun, 31 Dec 2023 12:07:52 -0800 (PST) MIME-Version: 1.0 References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <202312311738.3BVHctA1018336@freefriends.org> In-Reply-To: <202312311738.3BVHctA1018336@freefriends.org> From: Warner Losh Date: Sun, 31 Dec 2023 13:07:41 -0700 Message-ID: To: arnold@skeeve.com Content-Type: multipart/alternative; boundary="00000000000000af3d060dd3d27c" Message-ID-Hash: MBJY2DCSPAXKLW2IDWDWM6THRZ5EYDCJ X-Message-ID-Hash: MBJY2DCSPAXKLW2IDWDWM6THRZ5EYDCJ X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org, gtaylor@tnetconsulting.net X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Question about BSD disklabel history List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000000af3d060dd3d27c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 31, 2023 at 10:39=E2=80=AFAM 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, overlappin= g 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 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" i= s > > 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. . . . > --00000000000000af3d060dd3d27c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Dec 31, 2023 at 10:39=E2=80= =AFAM <arnold@skeeve.com> wr= ote:
The differe= nt 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=C2=A0in the disk driv= er 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 d= rivers included the
partition layout (IIRC, I didn't cross ve= rify).
=C2=A0
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<= /div>
partition. You could then patch the offset and length into the ke= rnel with
adb and use that area of the disk for swap space.
=
=C2=A0
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.

Whe= n I looked into it years ago, I convinced myself that SunOS
was t= he first to have it (since the very first version of SunOS 1.0
ha= d disk labels) and that all the other vendors followed suit within
a couple of years. Ultrix-11 had the fixed labels through its EOL.
<= div>I didn't see any disklable=C2=A0stuff in the Ultrix-32M that we hav= e, but
it was admittedly a quick look.
=C2=A0
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 c= hange 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 di= fferent from that, but quite
similar. This is why it's called= 4.3BSD format in many places, even though
it wasn't in the o= riginal 4.3BSD release.

OpenBSD and FreeBSD's= =C2=A0disklabels=C2=A0are 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 th= e shared history and divergent
evolution of the two systems. Open= BSD also supports both endians, while FreeBSD
only supports nativ= e endian. So these changes and different decisions lead to
the si= tuation today where it's hard to read them on each-other's systems.= Plus with
the new, larger disks FreeBSD has effectively abandone= d 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, e= tc. That's
a topic for another time...

Warner
=C2=A0
Grant Taylor via TUHS <tuhs@tuhs.org> wrote:

> Hi,
>
> I've found myself wondering about partitions inside of BSD disk la= bels.
>
> 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, u= nless it
> isn't, at which point it's the entire slice (BIOS / MBR partit= ion)
> containing the BSD disklabel and "d" is the entire disk.
>
> I also found something last night that indicated that OpenBSD uses dis= k
> labels somewhat differently than FreeBSD.
>
> Aside:=C2=A0 This is one of the dangers of wondering how something cur= ious
> came to be and why it came to be when working on 10-15 year old FreeBS= D
> systems.
>
>
>
> --
> Grant. . . .
--00000000000000af3d060dd3d27c--