Page MenuHomeFreeBSD

bectl: Add -n flag for the activate subcommand to prevent it from promoting cloned datasets
AbandonedPublic

Authored by arrowd on Sep 12 2024, 7:44 PM.
Tags
None
Referenced Files
F102379219: D46658.diff
Mon, Nov 11, 11:23 AM
Unknown Object (File)
Thu, Oct 24, 2:59 AM
Unknown Object (File)
Oct 2 2024, 9:45 PM
Unknown Object (File)
Oct 2 2024, 12:00 PM
Unknown Object (File)
Oct 1 2024, 7:22 PM
Unknown Object (File)
Sep 23 2024, 7:22 PM
Unknown Object (File)
Sep 20 2024, 1:59 PM
Unknown Object (File)
Sep 19 2024, 8:34 AM

Details

Reviewers
kevans
Group Reviewers
Contributor Reviews (src)
ZFS
Summary

Rationale for this change is following.

In my workflow I first create the recovery_point0 BE. But since it may be
booted in and changed somehow (and be broken), I also immediately create the
@clean snapshot.

Now if I want my default BE to be rolled back to the recovery point I run:

  • bectl rename default removeMe
  • bectl create -e recovery_point0@clean default
  • bectl activate default

But the last step destroys the @clean snapshot making it
impossible to perform the same operation second time. I understand that it is
not really destroyed but moved to default and I can use it to recreate
recovery_point0@clean, but I feel that there should be a way to opt-out from
the promotion during the BE activation.

The flag name is subject for bikeshedding.

For the context, the change that introduced current behaviour is https://reviews.freebsd.org/D40972

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 59513
Build 56400: arc lint + arc unit

Event Timeline

While at it I noticed that running make -C sbin/bectl makes it load /usr/include/be.h instead of lib/libbe/be.h. Not sure if this should be fixed.

It might be appropriate for sbin/bectl/bectl.8 to now explicitly mention the default implicit promotion in its activate description. As I remember, the historical text was not explicit at all about what to expect related to what promotion controls. But, with the change, both alternatives become possibilities.

I get it all wrong from the beginning. There is no need in this flag.