libbe: recursively promote deep BE datasets

[rcm]

Summary

beadm will recursively promote deep BE datasets. In order to match the bedam
behavior, we need to recursively iterate over child filesystems and promote them
along the way.

This patch further refines the work at https://reviews.freebsd.org/D40903

Sponsored by: Rubicon Communications, LLC ("Netgate")

Test Plan

The test case introduced in https://reviews.freebsd.org/D40903 has been
modified to test a simple deep BE case.

[kevans]

For future diffs, please include full context (-U999999) or use arc

lib/libbe/be.c

1323

I'm torn on whether we want to do it this way, or if we want to additionally push the origin check into be_zfs_promote_cb and keep running be_zfs_promote until we don't have any more cloned datasets to promote, just in case the sysadmin's done something crazy with some subordinates.

[rcm]

In D40972#932738, @kevans wrote:

For future diffs, please include full context (-U999999) or use arc

Thanks, I will do that moving forward

[rcm]

Added full context

[rcm]

lib/libbe/be.c

1323

I agree. I have addressed this case in my latest diff.

be_zfs_promote now returns a bool that can be used to determine if we encountered a dataset with an origin property set. If we did, we promote it and then iterate again, steeping deeper until we walk the tree without encountering a dataset with an origin prop.

[kevans]

Just a couple small style(9)-ish comments, but I can address these pre-commit. I think I'm happy with this version, though I might amend the test to, after the basics are verified as written, manually promote one of the two datasets so that we need two rounds for one dataset, one for the other, and make sure we get both done without an error.

lib/libbe/be.c

1273

No space between closing parenthesis and data

1277

Hanging line should be tabbed to the same level + 4 spaces, rather than the two tabs here

1278

No parentheses here

1290

No parentheses here

1291

No space between closing parenthesis and found-origin

[rcm]

I have updated the diff with the style(9) changes suggested

lib/libbe/be.c

1273

Thanks

1277

Thanks

1278

Thanks

1290

Thanks

1291

Thanks

[kevans]

I think I'm happy with this; will give others ~half a day or so more to object.

[arrowd]

I just bumped into this and I wonder what's the rationale to perform promotion during bectl activate.
I want to keep the BE snapshot I'm creating a new BE from, but activating new BE removes the snapshot (well, transfers it to the new BE's dataset).
Maybe we can have a command line flag to not perform the promotion?

[markmi_dsl-only.net]

This was a continuation/completion of https://reviews.freebsd.org/D40903 which reported:

This matches the beadm behavior; generally, we need to keep promoting
until the BE is no longer a clone from a snapshot. This fixes scenarios
where the dataset associated with a BE's origin is itself a clone,
activating the BE previously would promote it to a clone of the origin's
origin.

[netchild]

In D40972#1062704, @arrowd wrote:

I just bumped into this and I wonder what's the rationale to perform promotion during bectl activate.
I want to keep the BE snapshot I'm creating a new BE from, but activating new BE removes the snapshot (well, transfers it to the new BE's dataset).

Without the promotion, the currently active BE is a clone. If you want to delete the origin (after e.g. booting into the new one), it will not work as the clone has a reference of the snapshot in the source. By promoting the newly activated BE, the active BE is the parent instead if a child. This way you can delete the non-active BE. See zfsconcepts(7).