On 10/12/23 00:08, Mark Millard wrote:
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:
URL:
https://cgit.FreeBSD.org/src/commit/?id=989c5f6da99081b1f2b76ec09e91078e531e1250
commit 989c5f6da99081b1f2b76ec09e91078e531e1250
Author: Kyle Evans <kev...@freebsd.org>
AuthorDate: 2023-10-12 02:51:07 +0000
Commit: Kyle Evans <kev...@freebsd.org>
CommitDate: 2023-10-12 02:54:03 +0000
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
