(very OT) Ideal partition schemes (history of partitioning)

Polytropon freebsd at edvax.de
Sat Aug 29 13:44:21 UTC 2020

On Fri, 28 Aug 2020 23:08:30 -0400, Aryeh Friedman wrote:
> When installing another OS then FreeBSD (won't state which one to avoid
> flame wars) I noticed it's default partitioning scheme breaks the main (and
> only) drive on the system down into 50 GB chunks (in my case / and /home)
> by default (I over road to FreeBSD's default of one big partition for the
> whole drive [minus swap]).
> I was wondering what people think of different generalized partitioning
> schemes? (there is no right answer here but I might question your comments)

You are correct about the fact there is no "the correct way".
What you should implement in your partitioning layout depends
on what you want to achieve, and there usually are several
ways (with advantages and disadvantages) to accomplish that.

First of all, partitioning depends on your hardware: Is it
UEFI only, UEFI / BIOS (legacy mode), or BIOS only? And will
there be a non-FreeBSD system installed on the same disk or
SSD, so you can multi-boot? What system will it be? What
boot selection method will be used?

Most multi-OS settings seem to work best with BIOS + MBR.
Boot selection can either happen using a PF key at system
startup, if it's more than one disk, or you have a separate
software solution, like GRUB or FreeBSD's boot manager, if
all systems are on one and the same disk.

With MBR, you can have up to 4 "DOS primary partitions",
i. e., slices. FreeBSD needs only one, other systems may
need one or more. If 4 isn't enough, you need to remove
one, and put an "DOS extended partition" in the free slot,
which then can hold "logical volumes inside a DOS extended
partition". This is typically called EBR.

The limitations of MBR are no longer valid with GPT: Any
new partition gets a new number, and if you want to have
20 partitions, that's no problem - it's natively possible.
The problem could be systems not properly understanding
GPT layout, and if I remember correctly, FreeBSD's boot
manager does not support multiboot from GPT.

On systems that do not have BIOS or "legacy mode", if I
did understand everything correctly, MBR is not supported
unless a EFI partition has been prepared beforehand.
And in case of ... I won't name it to avoid trouble,
even that won't work - you need to enable a Compatibility
Support Module (if present!) and so on...; all this
because you "should" use UEFI + GPT.

It's actually quite complicated... ;-)

You can avoid all this for FreeBSD-only systems by not
using any partitioning at all - you just add labels (using
the disklabel / bsdlabel command). Note that only letters
'a' to 'h' are possible (with exception of 'c').

To summarize, you have the following usable (!) options:

	a) BIOS + dedicated

	b) BIOS + MBR

	c) BIOS + GPT

	d) UEFI + GPT

In case of MBR, FreeBSD gets one slice; in case of
GPT, FreeBSD gets as many partitions as it needs.
The partition types are also different for GPT and MBR,
and depending on the desired layout, the partitions you
need can change.

Within a slide, you can create multiple partitions. The
common approach today is to have one big / and some swap.
The idea of "functional partitioning" typically suggests
a layout like this:

			------------ device in /dev -----------
			dedicated	MBR		GPT
	/boot		-		-		ada0p1
	/		ada0a		ada0s1a		ada0p2
	swap		ada0b		ada0s1b		ada0p3
	/tmp		ada0d		ada0s1d		ada0p4
	/var		ada0e		ada0s1e		ada0p5
	/usr		ada0f		ada0s1f		ada0p6
	/opt		ada0g		ada0s1g		ada0p7
	/home		ada0h		ada0s1h		ada0p8

This is just a very simplified example.

Also remember that most other systems fail to understand
dedicated partitioning. The idea of "partitions within a
slice" comes from BSD coming from non-PC systems to the PC,
where MBR was required for multi-boot interoperability (to
a certain, often quite limited degree). With GPT, there are
plenty of types, so this is no longer needed.

> Also why are partitioned need at all? (both currently and historically)

In ye olden tymes, storage was expensive. There were systems
that booted from 8" floppy disks or small hard disks, but
those could not contain the whole filesystem with all the
programs. So for example, / was on a small but fast disk,
this was enough to bring the system up into single-user
mode. From there on, /usr, /tmp, /var and finally /home were
mounted from bigger, but often smaller disks. For experiments,
the disk packs (usually removable hard disks) could be
exchanged, i. e., boot the system, but use an alternative
/usr partition (disk) for testing. The idea was to have
the data used most to be on the faster drives (often more
expensive, sometimes also smaller), and the stuff not
needed to be fast on slower drives (often bigger).

At that time, a minicomputer system running a UNIX often
had multiple disk deives with removable media, and they
didn't have to be of the same kind (and parameters).

In today's modern times, UFS partitions can still serve a
purpose where ZFS cannot be used. Note that ZFS conveniently
solves all those problems. :-)

For example, you can separate filesystems such as /tmp from
the rest of your system. Imagine a process writing to /tmp,
writing and writing, on and on, and now you're out of disk
space, the system gets in trouble, no log files can be written
because there's no space in /var (as it is on / along with
/tmp). With /tmp being a separate partition, only that one
gets filled, but everything else still works. Also think
about the partition-wise backup (dump and restore) which is
very useful if you don't want to deal with separate files.
And also mount options can be interesting, such as optimization
for specific kinds of storage (noasync, noatime) or for 
security (noexec). For security reasons, you could also have
partitions mounted only when needed and authorized (not a
typical use case on a home PC, but possible).

Using ZFS, you can apply even more options to optimize
the use of partitions.

And also consider encrypted partitions: Their mountpoint
is empty, they only become available after being unlocked.
Their location within the VFS hierarchy can also be
significant (shared access or individual access).

That was quite a hodgepodge of statements, but I'm sure you
will be able to extract some useful information from it, and
those can be the source of further questions. :-)

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

More information about the freebsd-questions mailing list