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 22652 invoked from network); 1 Jan 2024 02:22:35 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 1 Jan 2024 02:22:35 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id C686B43EAD; Mon, 1 Jan 2024 12:22:26 +1000 (AEST) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by minnie.tuhs.org (Postfix) with ESMTPS id 38CBB43EA4 for ; Mon, 1 Jan 2024 12:22:20 +1000 (AEST) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-a27f0963a80so48179966b.0 for ; Sun, 31 Dec 2023 18:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704075738; x=1704680538; 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=8Ia5Oc7tvHDdHuZh4ebtUVnJ+oXj9GVfEHm91VcmpR4=; b=z5XUqi0Kld/wHkGRejHozRO4ToQoYuEi9vGSqTUk5wINEvMvAbiWy/WzTWbNsNoDP1 pk5/plGL043VYq664WPpxosiiTaFeW6qaY62wYcRRhaBNVEtAnkA3udx1wu4/YqFy+Hw oxgc/VUoQDbxoPwKPUvBrge7kjKXVwsF4SOj9lUvFsO5YAjT9CLccnSTNk1JmBCCu7d6 dzRwDXj6nNOAcNvJdNm5XMP+eKF3JfXJSW6dc2bTBUlyYIuATSrJhYXIZLr7zDc7JB2Y aBJc9ZNhFjjdaf4gkMXOhdKR98mib5JVS1k9S0Gi4phvgtijzJPHJFNQKUvxmOaZFFUJ 415w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704075738; x=1704680538; 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=8Ia5Oc7tvHDdHuZh4ebtUVnJ+oXj9GVfEHm91VcmpR4=; b=OUalozC9lnHS9UG8pKTyTo8/VsdlNjuP9vS5FxBAf44+FCMdW9DrOyOsnaU10p5aRN qtL6vTiZc+PmUVbVCN69zBzMWIUOdRXSdbMXLs4eXcYrSl1koEKJqnvKDqYVdZHbYjwo pxLbwSx+HT2QxTMqqAnXedAEjIdJI86KqlUQdGftQQkr0a4lF47QrRu7Sly11EjbSCx9 kwDijYlZW6KATgbwXvd97zF3pX4RlBEWU3z4zKSpcmJ/BSibQZ2mw4SZzq6RiHHhk9pN d72CIHfCh2RfO/m9Thg/Pv+T20S2yBPVLvAXUEvcJbc8QaPfMWnrr/+dWRwBKc14w+UH Ca9g== X-Gm-Message-State: AOJu0Yz9jnqb8uNYFIBiozZpESbZhq/+CFVEEWXVy5P/VVwTaFm9cDsO viyOS3IzuAoqYWJ44M9qWiC//dPZokGf+pqs4xL1mn0i9J+e+eh61/RVdxxPIok= X-Google-Smtp-Source: AGHT+IGqejuXL3nRwgzVyZLU/OLgHw1tdRs3wJe7Qqpv0K63J6a8/3KxU03ajEh6naRsRP4kYOhNjTDLWONq7KYlRvI= X-Received: by 2002:a17:906:c189:b0:a26:9585:560 with SMTP id g9-20020a170906c18900b00a2695850560mr5821229ejz.153.1704075738235; Sun, 31 Dec 2023 18:22:18 -0800 (PST) MIME-Version: 1.0 References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <202312311738.3BVHctA1018336@freefriends.org> In-Reply-To: From: Warner Losh Date: Sun, 31 Dec 2023 19:22:06 -0700 Message-ID: To: Grant Taylor Content-Type: multipart/alternative; boundary="0000000000000c5529060dd90df1" Message-ID-Hash: GXB62BSI45YJVDZMM7SPMK4HNFPY24ZJ X-Message-ID-Hash: GXB62BSI45YJVDZMM7SPMK4HNFPY24ZJ 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: The Eunuchs Hysterical Society 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: --0000000000000c5529060dd90df1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 8 On Sun, Dec 31, 2023, 5:26=E2=80=AFPM Grant Taylor via TUHS = wrote: > On 12/31/23 11:38, arnold@skeeve.com wrote: > > The different overlapping partitions predates disk labels. > > Okay. That in and of itself doesn't surprise me much that a convention > of overlapping partitions was carried forward from the driver based > partitioning into label based partitioning. > Many editors dont let you do this... > Up to and including 4.3 BSD, to change the size of partitions on a > > particular disk, you had to recompile the kernel. > > So I've learned over the last couple of years as I read more about Unix > history. > > > 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. > > I'm not understanding how /overlapping/ partitions helps make use of > portions of disks. > Maybe I should back up and ask for clarification. What /overlapping/ > partitions means in this context? > It means you either use one set of non overlapping partitions or another set. They were setup in clever ways My naive assumption was that partition -- I use that term loosely -- "c" > overlaps / contains / all other partitions on the disk; "a", "b", and > maybe "d". > > I'm eliding the "c" MBR partition vs "d" entire drive" distinction for > the moment. > > I see some value in the "c" partition being the entire disk as used by > BSD so that it's possible to point backup / restore / copy utilities at > the entire disk. > > But I don't understand value in having partitions overlap / contain each > other's blocks, save for backup via "c". > > I do see some value in extending the "c" is the entire MBR partition > methodology to "d" is the entire disk containing multiple MBR > partitions. Again, the value seems to be in backup and recovery. > > But I still simply do not understand why I would ever want partition "e" > to be blocks 100-199, partition "f" to be blocks 195-299, and partition > "g" to be blocks 295-399. What value is there in having partitions e, > f, and g overlap each other? > > I get dd if=3D/dev/0c of=3D/dev/rmt. Or even /dev/= 0d. > > I fail to understand why I'd ever want other partitions to overlap. > It's more like you can use two or three partitions with non overlapping sets that cover the whole disk. > 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. > > Sure. But I don't see what that has to do with overlapping partitions. > > I'd naively think that I could do something like the following: > > dd if=3D/dev/0a of=3D/dev/1a > > And get the same effect. > > > 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. > > "a" for root makes some intuitive sense as the root file system is > required to do anything else. > > Then when you want swap, the next partition is "b". > > Wanting another partition that is the entire disk (as seen by BSD) makes > some logical sense to me too, so "c". > > Were subsequent partitions sort of used as needed and had less > consistency? Especially when "d" because the entire disk containing > multiple MBR partitions when "c" was restricted to the MBR partition the > label was in? > > Aside: > > Would that mean that the following "d" partitions would be the same > thing, as in the entire /dev/ad0 disk? > > /dev/ad0s0d > /dev/ad0s1d > > Wherein I'm borrowing the FreeBSD slice nomenclature -- as I understand > it -- to identify the first (zero) and second (one) MBR partition on > /dev/ad0 > Yes. But ancient Unix didn=E2=80=99t have nested partitioning schemes like FreeB= SD supports... History and how we got to where we are today can be both very confusing > and even more enlightening once you understand it. What's more is that > once you understand it, things start making more intuitive sense when > you look at them. > Think more of a limited number of ways to mix and match for greater flexibility w/o editing the tables. A silly example: a is first 2/3 of the disk. B is 2nd 2/3, c d and e are 1/3 each. Warner --=20 > Grant. . . . > --0000000000000c5529060dd90df1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
8

On Sun, Dec 31, 2023, 5:26=E2=80=AFPM Grant Taylor vi= a TUHS <tuhs@tuhs.org> wrote:
On 12/31/23 11:38, arnold@skeeve.com wr= ote:
> The different overlapping partitions predates disk labels.

Okay.=C2=A0 That in and of itself doesn't surprise me much that a conve= ntion
of overlapping partitions was carried forward from the driver based
partitioning into label based partitioning.


Many= editors dont let you do this...

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

So I've learned over the last couple of years as I read more about Unix=
history.

> 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.

I'm not understanding how /overlapping/ partitions helps make use of portions of disks.

=

Maybe I should back up and ask for clarification.=C2=A0 What /overlapping/ =
partitions means in this context?

It means you either use one set of non ove= rlapping partitions or another set. They were setup in clever ways=C2=A0

My naive assumption was that partition -- I use that term loosely -- "= c"
overlaps / contains / all other partitions on the disk; "a", &quo= t;b", and
maybe "d".

I'm eliding the "c" MBR partition vs "d" entire dri= ve" distinction for
the moment.

I see some value in the "c" partition being the entire disk as us= ed by
BSD so that it's possible to point backup / restore / copy utilities at=
the entire disk.

But I don't understand value in having partitions overlap / contain eac= h
other's blocks, save for backup via "c".

I do see some value in extending the "c" is the entire MBR partit= ion
methodology to "d" is the entire disk containing multiple MBR partitions.=C2=A0 Again, the value seems to be in backup and recovery.

But I still simply do not understand why I would ever want partition "= e"
to be blocks 100-199, partition "f" to be blocks 195-299, and par= tition
"g" to be blocks 295-399.=C2=A0 What value is there in having par= titions e,
f, and g overlap each other?

I get dd if=3D/dev/<something>0c of=3D/dev/rmt.=C2=A0 Or even /dev/&l= t;something>0d.

I fail to understand why I'd ever want other partitions to overlap.
=

It&#= 39;s more like you can use two or three partitions with non overlapping set= s that cover the whole disk.

> It was also helpful, if you had the drives, to nightly dd your real > root to the "a" partition on another, identical drive, so th= at you
> could boot the backup root in an emergency.

Sure.=C2=A0 But I don't see what that has to do with overlapping partit= ions.

I'd naively think that I could do something like the following:

=C2=A0 =C2=A0 dd if=3D/dev/<something>0a of=3D/dev/<something>1= a

And get the same effect.

> 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.

"a" for root makes some intuitive sense as the root file system i= s
required to do anything else.

Then when you want swap, the next partition is "b".

Wanting another partition that is the entire disk (as seen by BSD) makes some logical sense to me too, so "c".

Were subsequent partitions sort of used as needed and had less
consistency?=C2=A0 Especially when "d" because the entire disk co= ntaining
multiple MBR partitions when "c" was restricted to the MBR partit= ion the
label was in?

Aside:

Would that mean that the following "d" partitions would be the sa= me
thing, as in the entire /dev/ad0 disk?

/dev/ad0s0d
/dev/ad0s1d

Wherein I'm borrowing the FreeBSD slice nomenclature -- as I understand=
it -- to identify the first (zero) and second (one) MBR partition on
/dev/ad0

Yes.

But ancie= nt Unix didn=E2=80=99t have nested partitioning schemes like FreeBSD suppor= ts...

History and how we got to where we are today can be both very confusing and even more enlightening once you understand it.=C2=A0 What's more is= that
once you understand it, things start making more intuitive sense when
you look at them.

<= div dir=3D"auto">Think more of a limited number of ways to mix and match fo= r greater flexibility w/o editing the tables.

A silly example: a is first 2/3 of the disk. B is 2nd= 2/3, c d and e are 1/3 each.

Warner

--
Grant. . . .
--0000000000000c5529060dd90df1--