1 Jan
2024
1 Jan
'24
8:22 a.m.
8
On Sun, Dec 31, 2023, 5:26 PM Grant Taylor via TUHS <tuhs(a)tuhs.org> wrote:
On 12/31/23 11:38, arnold(a)skeeve.com wrote:
Many editors dont let you do this...
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.
Up to and including 4.3 BSD, to change the size of
partitions on a
Maybe I should back up and ask for clarification. What /overlapping/
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.
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
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
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
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. . . .