Re: git: 989c5f6da990 - main - freebsd-update: create deep BEs by default [really about if -r for bectl create should just go away]
Am 2023-10-12 07:08, schrieb Mark Millard: I use the likes of: BE Active Mountpoint Space Created build_area_for-main-CA72 - - 1.99G 2023-09-20 10:19 main-CA72NR / 4.50G 2023-09-21 10:10 NAMECANMOUNT MOUNTPOINT zopt0 on/zopt0 . . . zopt0/ROOT onnone zopt0/ROOT/build_area_for-main-CA72 noautonone zopt0/ROOT/main-CA72noautonone zopt0/poudriere on /usr/local/poudriere zopt0/poudriere/dataon /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/wrkdirson /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 [...] 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. Additionally/complementary to what Kyle said... The -r option is about zop0/ROOT/main-CA72 zop0/ROOT/main-CA72/subDS1 zop0/ROOT/main-CA72/subDS2 A shallow clone is only taking zop0/ROOT/main-CA72 into account, while a -r clone is also cloning subDS1 and subDS2. So as Kyle said, your (and my) use case are not affected by this. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
Re: git: 989c5f6da990 - main - freebsd-update: create deep BEs by default [really about if -r for bectl create should just go away]
On 10/12/23 00:08, Mark Millard wrote: Kyle Evans wrote on Date: Thu, 12 Oct 2023 02:54:13 UTC : The branch main has been updated by kevans: URL: https://cgit.FreeBSD.org/src/commit/?id=989c5f6da99081b1f2b76ec09e91078e531e1250 commit 989c5f6da99081b1f2b76ec09e91078e531e1250 Author: Kyle Evans AuthorDate: 2023-10-12 02:51:07 + Commit: Kyle Evans CommitDate: 2023-10-12 02:54:03 + freebsd-update: create deep BEs by default 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'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. -r should do the right thing in all cases, the only real difference from w/o -r is that it'll recurse into subordinates of the BE dataset. For the common case, including yours, that means there's no functional difference and negligible overhead added (because we still have to try to iterate over childfren, even if there are none). Thanks, Kyle Evans
RE: git: 989c5f6da990 - main - freebsd-update: create deep BEs by default [really about if -r for bectl create should just go away]
Kyle Evans wrote on Date: Thu, 12 Oct 2023 02:54:13 UTC : > The branch main has been updated by kevans: > > URL: > https://cgit.FreeBSD.org/src/commit/?id=989c5f6da99081b1f2b76ec09e91078e531e1250 > > commit 989c5f6da99081b1f2b76ec09e91078e531e1250 > Author: Kyle Evans > AuthorDate: 2023-10-12 02:51:07 + > Commit: Kyle Evans > CommitDate: 2023-10-12 02:54:03 + > > freebsd-update: create deep BEs by default > > 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-CA72NR / 4.50G 2023-09-21 10:10 NAMECANMOUNT MOUNTPOINT zopt0 on/zopt0 . . . zopt0/ROOT onnone zopt0/ROOT/build_area_for-main-CA72 noautonone zopt0/ROOT/main-CA72noautonone zopt0/poudriere on/usr/local/poudriere zopt0/poudriere/dataon/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/wrkdirson /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/dbnoauto/var/db zopt0/var/db/pkgon/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 noautonone zopt0/ROOT/main-CA72noautonone 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
