Date: Sat, 29 Aug 2020 15:44:17 +0200 From: Polytropon <freebsd@edvax.de> To: Aryeh Friedman <aryeh.friedman@gmail.com> Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: (very OT) Ideal partition schemes (history of partitioning) Message-ID: <20200829154417.8dd5f83d.freebsd@edvax.de> In-Reply-To: <CAGBxaXkf53K4EHtq9cDaRm3MOZZixyBq-aQfZ7upHo-wUwrmCg@mail.gmail.com> References: <CAGBxaXkf53K4EHtq9cDaRm3MOZZixyBq-aQfZ7upHo-wUwrmCg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200829154417.8dd5f83d.freebsd>