[TUHS] Re: Question about BSD disklabel history

[Warner Losh <imp@bsdimp.com>]

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

8

On Sun, Dec 31, 2023, 5:26 PM Grant Taylor via TUHS <tuhs@tuhs.org> 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=/dev/<something>0c of=/dev/rmt.  Or even /dev/<something>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=/dev/<something>0a of=/dev/<something>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’t have nested partitioning schemes like FreeBSD
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

-- 
> Grant. . . .
>

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