From owner-freebsd-questions@freebsd.org Sat Aug 29 13:44:21 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CC4333B0B2D for ; Sat, 29 Aug 2020 13:44:21 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BdyPJ4Chsz4Tn4 for ; Sat, 29 Aug 2020 13:44:19 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([178.5.94.186]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPA (Nemesis) id 1N94uf-1khj8w3Dmx-0167PJ; Sat, 29 Aug 2020 15:44:18 +0200 Date: Sat, 29 Aug 2020 15:44:17 +0200 From: Polytropon To: Aryeh Friedman Cc: FreeBSD Mailing List Subject: Re: (very OT) Ideal partition schemes (history of partitioning) Message-Id: <20200829154417.8dd5f83d.freebsd@edvax.de> In-Reply-To: References: Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:ioW97rixS7Q8gDiJlw/I2tUDPh5WT00r698C8RD2KHoi4aRn4fg Rc2onXwAPBhUS8dzZHrZJxppCI7Rbh1r500x0WqgRrnN+9/fGqR08fl59OPV+LNum+2xZ7v P7khxXBLg0rs8zOeZmTJOQcqqAg6Mssj5tyTFTDR+QTgjEVSKbkvhqVcVzk4FtBFjPEaem6 3ZUC5i4cVIome/pt/sMZQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:e2FASlhF1K8=:xp0m7M6372hSEGiL61poud 3LElqagBfhL+rrOc+AGoEp2Qe+GGRY7U6x/sbEUd0Fai7PgYyrV56m2ym8RCRK/6IhJgT7nmU F9ETLc0OFD4s7mYvahFDPAG8vm5Ij0RPpFr19VrJnWLEggttuXvZ7BWQ5UUJG9TLbiWFj5jKp YRXYw+YAd01EDYw0yKIQm5kTu5jXXw1xwUfFCcxUQkNeAuwQqUPfzalqbBplgzXv8XULnoiuZ Z//oj/FdcoR1szrcC9rA4y5uuy70T4ZA7Ruy5IZ0uBY6JfiVi4Mh/+aF44EAYXOxDz3TZbSqH rlXLdMiOOAymHwONQDgiuhkWIb8QtIWfKOO1Ad+CDQq6piQmgHaqPz5luvZcRoQerNWRXh+9f r0LnpfFDZgazZ9KkfXsZe4GXXvACuYzxldvwwWuLW0HwZfL+AZ7E8ueeayfzxD4uac81gtr9s 9WhtiwTEAdtsa/KXP+uhKVwsWS2eOcQCswTJBUNpL7+/0YPfw3rowfad2GJ4DXo/ZVf8ssEgs g7FoOGbXVCDmMjmxHFTN1icSr/icwvtiX0YwX2Da83Rb8HOTfE6xgBXr3WKXbb2W3yyx+Bcjv w6FeWo9zPT/psj7BqZxFwzkaP7AEUWZA+OouoxVXosKvGxih4LyBmblyS+Iqlc2TafgtOSdU1 MguVYFmOP9u4DsasN6et3YDj/hlKil3vfIWYELGNIRmefteP3mzhDc9cuf0KPUEV09gcUswY5 sZ5yubR3vzvnOu7eZrtnfxNiV3LINT6zF50UqoKOZkuKrxJQeDHJGN43gm29D8rzmpFTdE84v rhmyerGd6oIGoyQImgYZAAVtjmCWbOf/hAUzigOG62ymrRZDdtXRdIW0wdQp44TLGvrak5/ X-Rspamd-Queue-Id: 4BdyPJ4Chsz4Tn4 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 217.72.192.74) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [4.06 / 15.00]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8560, ipnet:217.72.192.0/20, country:DE]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[178.5.94.186:received]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.12)[0.124]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.62)[0.625]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.91)[0.915]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[217.72.192.74:from]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[217.72.192.74:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2020 13:44:21 -0000 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, ...