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 <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 <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
>>
>> 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