Date: Wed, 11 Oct 2023 22:08:43 -0700 From: Mark Millard <marklmi@yahoo.com> To: Kyle Evans <kevans@FreeBSD.org>, Current FreeBSD <freebsd-current@freebsd.org> Subject: RE: git: 989c5f6da990 - main - freebsd-update: create deep BEs by default [really about if -r for bectl create should just go away] Message-ID: <6AA52432-32DF-4C2D-B061-F207521F7397@yahoo.com> References: <6AA52432-32DF-4C2D-B061-F207521F7397.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kyle Evans <kevans_at_FreeBSD.org> wrote on Date: Thu, 12 Oct 2023 02:54:13 UTC : > The branch main has been updated by kevans: >=20 > URL: = https://cgit.FreeBSD.org/src/commit/?id=3D989c5f6da99081b1f2b76ec09e91078e= 531e1250 >=20 > commit 989c5f6da99081b1f2b76ec09e91078e531e1250 > Author: Kyle Evans <kevans@FreeBSD.org> > AuthorDate: 2023-10-12 02:51:07 +0000 > Commit: Kyle Evans <kevans@FreeBSD.org> > CommitDate: 2023-10-12 02:54:03 +0000 >=20 > freebsd-update: create deep BEs by default >=20 > The -r flag to bectl needs to go away, and we need to just do the = right > thing. In the meantime, we can apply an -r in freebsd-update as a > minimal fix to stop creating partial backups in these (non-default) = deep > BE setups. These notes about not about the specific commit, nor about if -r like = behavior should be the default for bectl create. The notes are about if the currently "not -r" bectl create behavior = should become impossible vs. being supported --or, more accurately, what layouts are = possible. (In case I'm misreading the implications of the -r wording.) The primary = reason I use zfs is to use bectl, not for the other kinds of reasons zfs is = typically used for. I use the likes of: BE Active Mountpoint Space Created build_area_for-main-CA72 - - 1.99G 2023-09-20 10:19 main-CA72 NR / 4.50G 2023-09-21 10:10 NAME CANMOUNT MOUNTPOINT zopt0 on /zopt0 . . . zopt0/ROOT on none zopt0/ROOT/build_area_for-main-CA72 noauto none zopt0/ROOT/main-CA72 noauto none zopt0/poudriere on = /usr/local/poudriere zopt0/poudriere/data on = /usr/local/poudriere/data zopt0/poudriere/data/.m on = /usr/local/poudriere/data/.m zopt0/poudriere/data/cache on = /usr/local/poudriere/data/cache zopt0/poudriere/data/images on = /usr/local/poudriere/data/images zopt0/poudriere/data/logs on = /usr/local/poudriere/data/logs zopt0/poudriere/data/packages on = /usr/local/poudriere/data/packages zopt0/poudriere/data/wrkdirs on = /usr/local/poudriere/data/wrkdirs zopt0/poudriere/jails on = /usr/local/poudriere/jails zopt0/poudriere/ports on = /usr/local/poudriere/ports zopt0/tmp on /tmp zopt0/usr off /usr zopt0/usr/13_0R-src on /usr/13_0R-src zopt0/usr/alt-main-src on /usr/alt-main-src zopt0/usr/home on /usr/home zopt0/usr/local on /usr/local zopt0/usr/main-src on /usr/main-src zopt0/usr/ports on /usr/ports zopt0/usr/src on /usr/src zopt0/var off /var zopt0/var/audit on /var/audit zopt0/var/crash on /var/crash zopt0/var/db noauto /var/db zopt0/var/db/pkg on /var/db/pkg zopt0/var/db/ports on /var/db/ports zopt0/var/log on /var/log zopt0/var/mail on /var/mail zopt0/var/tmp on /var/tmp where every "CANMOUNT on" for a zopt0/[a-z]... prefixed row ( not zopt0/ROOT/* ) is used when booting any of: zopt0/ROOT/build_area_for-main-CA72 noauto none zopt0/ROOT/main-CA72 noauto none So: shared, not duplicated. The update sequence creates a snapshot of zopt0/ROOT/main-CA72 and then creates a zopt0/ROOT/new-main-CA72 from that which is then mounted and that is what the installkernel and installworld update. Dismount. Temporarily activate it. Reboot. Destroy build_area_for-main-CA72 . Rename main-CA72 to build_area_for-main-CA72 . Rename new-main-CA72 to main-CA72 . (It, then, again looks like the above.) I sometimes also temporarily have a zopt0/ROOT/alt-main-CA72 that also shares to avoid duplication. (I'll not get into the details, but build_area_for-main-CA72 is used to do the buildworld buildkernel and is what I can revert to in case of problems discovered later. I've not shown the build tree areas above, just to keep things simpler. They too are shared across the BE's.) I've no reason to want to maintain duplicates of any of that " shared across zopt0/ROOT/* " material: no deep BE setup desired. I've got such a set up (up to naming differences) as my default boot media for each of: ThreadRipper 1950X, HoneyComb, Windows DevKit 2023, MACCHIATObin Double Shot. I also sometimes use such boot media with the 8 GiByte RPI4B's. (The smaller capacity systems [all aarch64/armv7] basically just boot UFS media --that I normally produce from the HoneyCmb's bectl based boot context.) If such ends up as unsupportable, it will effectively eliminate my reason for using bectl (and, so, zfs): the sharing is important to my use. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6AA52432-32DF-4C2D-B061-F207521F7397>