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
Unknown Object (File)
Mon, Dec 23, 8:07 AM
Unknown Object (File)
Nov 20 2024, 8:30 PM
Unknown Object (File)
Nov 20 2024, 8:30 PM
Unknown Object (File)
Nov 20 2024, 8:30 PM
Unknown Object (File)
Nov 20 2024, 8:29 PM
Unknown Object (File)
Nov 13 2024, 8:43 PM
Unknown Object (File)
Nov 11 2024, 11:23 AM
Unknown Object (File)
Oct 24 2024, 2:59 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.