libbe: fix build against sysutils/openzfs, part 1

This is the half of the changes required that work as-is with both in-tree
ZFS and the new hotness, sysutils/openzfs. Highlights are less dependenc

libbe: fix build against sysutils/openzfs, part 1

This is the half of the changes required that work as-is with both in-tree
ZFS and the new hotness, sysutils/openzfs. Highlights are less dependency
on header pollution (from somewhere) and using 'mnttab' instead of
'extmnttab'. In the in-tree ZFS, the latter is a #define for the former,
but in the port extmnttab is actually a distinct struct that's a super-set
of mnttab. We really want mnttab here anyways, so just use it.

show more ...

libbe(3): Fix destroy of imported BE w/ AUTOORIGIN

Imported BE, much like the activated BE, will not have an origin that we can
fetch/examine for destruction. be_destroy should not return BE_ERR_NOO

libbe(3): Fix destroy of imported BE w/ AUTOORIGIN

Imported BE, much like the activated BE, will not have an origin that we can
fetch/examine for destruction. be_destroy should not return BE_ERR_NOORIGIN
for failure to get the origin property for BE_DESTROY_AUTOORIGIN, because
we don't really know going into it that there's even an origin to be
destroyed.

BE_DESTROY_NEEDORIGIN has been renamed to BE_DESTROY_WANTORIGIN because only
a subset of it *needs* the origin, so 'need' is too strong of verbiage.

This was caught by jenkins and the bectl tests, but kevans failed to run the
bectl tests prior to commit.

Reported by: lwhsu

show more ...

libbe(3): add needed bits for be_destroy to auto-destroy some origins

New BEs can be created from either an existing snapshot or an existing BE.
If an existing BE is chosen (either implicitly via 'b

libbe(3): add needed bits for be_destroy to auto-destroy some origins

New BEs can be created from either an existing snapshot or an existing BE.
If an existing BE is chosen (either implicitly via 'bectl create' or
explicitly via 'bectl create -e foo bar', for instance), then bectl will
create a snapshot of the current BE or "foo" with be_snapshot, with a name
formatted like: strftime("%F-%T") and a serial added to it.

This commit adds the needed bits for libbe or consumers to determine if a
snapshot names matches one of these auto-created snapshots (with some light
validation of the date/time/serial), and also a be_destroy flag to specify
that the origin should be automatically destroyed if possible.

A future commit to bectl will specify BE_DESTROY_AUTOORIGIN by default so we
clean up the origin in the most common case, non-user-managed snapshots.

show more ...

Merge ^/head r352436 through r352536.

fixup up fallout from r352447 in libbe

I totally forgot that we now have another in-tree consumer of libzfs.

MFC after: 3 days
X-MFC with: r352447

MFHead @347527

Sponsored by: The FreeBSD Foundation

libbe: set mountpoint=none in be_import

If we're going to set a mountpoint at all, mountpoint=none makes more sense
than mountpoint=/.

MFC after: 3 days

libbe(3): Copy received properties as well

This was inherently broken on send|recv datasets.

Reported and tested by: Wes Maag <jwmaag gmail com>
MFC after: 3 days

libbe(3): allow creation of arbitrary depth boot environments

libbe currently only provides an API to create a recursive boot environment,
without any formal support for intentionally limiting the d

libbe(3): allow creation of arbitrary depth boot environments

libbe currently only provides an API to create a recursive boot environment,
without any formal support for intentionally limiting the depth. This
changeset adds an API, be_create_depth, that may be used to arbitrarily
restrict the depth of the new BE.

Submitted by: Rob Fairbanks <rob.fx907 gmail com>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D18564

show more ...

libbe(3): use libzfs name validation for datasets/snapshot names

Our home-rolled solution didn't quite capture all of the details, and we
didn't actually validate snapshot names at all. zfs_name_val

libbe(3): use libzfs name validation for datasets/snapshot names

Our home-rolled solution didn't quite capture all of the details, and we
didn't actually validate snapshot names at all. zfs_name_valid captures the
important details, but it doesn't necessarily expose the errors that we're
wanting to see in the be_validate_* functions. Validating lengths
independently, then the names, should make this a non-issue.

show more ...

MFHead@r345880

libbe(3): Add a serial to the generated snapshot names

To use bectl in an example, when one creates a new boot environment with
either `bectl create <be>` or `bectl create -e <otherbe> <be>`, libbe

libbe(3): Add a serial to the generated snapshot names

To use bectl in an example, when one creates a new boot environment with
either `bectl create <be>` or `bectl create -e <otherbe> <be>`, libbe will
take a snapshot of the original boot environment to clone. Previously, this
used %F-%T date format as the snapshot name, but this has some limitations-
attempting to create multiple boot environments in quick succession may
collide if done within the same second.

Tack a serial onto it to reduce the chances of a collision... we could still
collide if multiple processes/threads are creating boot environments at the
same time, but this is likely not a big concern as this has only been
reported as occurring in freebsd-ci setup.

MFC after: 3 days

show more ...

libbe: Fix zfs_is_mounted check w/ snapshots

'be_destroy' can destroy a boot environment (by name) or a given snapshot.
If the target to be destroyed is a dataset, check if it's mounted. We don't
wa

libbe: Fix zfs_is_mounted check w/ snapshots

'be_destroy' can destroy a boot environment (by name) or a given snapshot.
If the target to be destroyed is a dataset, check if it's mounted. We don't
want to check if the origin dataset is mounted when destroying a snapshot.

PR: 236043
Submitted by: Rob Fairbanks <rob.fx907 gmail com>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D19650

show more ...

MFhead@r344270

Merge ^/head r343956 through r344177.

libbe(3): Fix be_destroy behavior w.r.t. deep BE snapshots and -o

be_destroy is documented to recursively destroy a boot environment. In the
case of snapshots, one would take this to mean that thes

libbe(3): Fix be_destroy behavior w.r.t. deep BE snapshots and -o

be_destroy is documented to recursively destroy a boot environment. In the
case of snapshots, one would take this to mean that these are also
recursively destroyed. However, this was previously not the case.
be_destroy would descend into the be_destroy callback and attempt to
zfs_iter_children on the top-level snapshot, which is bogus.

Our alternative approach is to take note of the snapshot name and iterate
through all of fs children of the BE to try destruction in the children.

The -o option is also fixed to work properly with deep BEs. If the BE was
created with `bectl create -e otherDeepBE newDeepBE`, for instance, then a
recursive snapshot of otherDeepBE would have been taken for construction of
newDeepBE but a subsequent destroy with BE_DESTROY_ORIGIN set would only
clean up the snapshot at the root of otherDeepBE: ${BEROOT}/otherDeepBE@...

The most recent iteration instead pretends not to know how these things
work, verifies that the origin is another BE and then passes that back
through be_destroy to DTRT when snapshots and deep BEs may be in play.

MFC after: 1 week

show more ...

libbe(3): Add a destroy option for removing the origin

Currently origin snapshots are left behind when a BE is destroyed, whether
it was an auto-created snapshot or explicitly specified via, for exa

libbe(3): Add a destroy option for removing the origin

Currently origin snapshots are left behind when a BE is destroyed, whether
it was an auto-created snapshot or explicitly specified via, for example,
`bectl create -e be@mysnap ...`.

Removing it automatically could be argued as a POLA violation in some
circumstances, so provide a flag to be_destroy for it. An accompanying
option will be added to bectl(8) to utilize this.

Some minor style/consistency nits in the affected areas also addressed.

Reported by: Shawn Webb
MFC after: 1 week

show more ...

Merge ^/head r343320 through r343570.

libbe(3): simplify import, allow replication streams

Previously, we directly used libzfs_core's lzc_receive to import to a
temporary snapshot, then cloned the snapshot and setup the properties. This

libbe(3): simplify import, allow replication streams

Previously, we directly used libzfs_core's lzc_receive to import to a
temporary snapshot, then cloned the snapshot and setup the properties. This
failed when attempting to import replication streams with questionable
error.

libzfs's zfs_receive is a much better fit here, so we now use it instead
with the destination dataset and let libzfs take care of the dirty details.
be_import is greatly simplified as a result.

Reported by: Marie Helene Kvello-Aune <freebsd@mhka.no>
MFC after: 1 week

show more ...

libbe(3): move altroot augmentation bits around a little bit

We could perhaps have a method that does this given a dataset, but it's yet
clear that we'll always want to bypass the altroot when we gr

libbe(3): move altroot augmentation bits around a little bit

We could perhaps have a method that does this given a dataset, but it's yet
clear that we'll always want to bypass the altroot when we grab the
mountpoint. For now, we'll refactor things a bit so we grab the altroot
length when libbe is initialized and have a common method that does the
necessary augmentation (replace with / if it's the root, return a pointer to
later in the string if not).

This will be used in some upcoming work to make be_mount work properly for
deep BEs.

MFC after: 1 week

show more ...

libbe(3): Don't allow bootfs to be destroyed

Previously, the following sequence of events was feasible under some
circumstance:

bectl create test
bectl activate test
# the test BE dataset gets prom

libbe(3): Don't allow bootfs to be destroyed

Previously, the following sequence of events was feasible under some
circumstance:

bectl create test
bectl activate test
# the test BE dataset gets promoted and set as bootfs
bectl destroy test

I was unable to reproduce the destroy succeeding, but we should be rejecting
this before it even gets to libzfs because it would leave the system in an
inconsistent state. Forcing the user to be explicit as to which environment
should be activated instead is much better.

Reported by: Graham Perrin <grahamperrin@gmail.com>
MFC after: 3 days

show more ...

Merge ^/head r340427 through r340868.

libbe(3): Handle non-ZFS rootfs better

If rootfs isn't ZFS, current version will emit an error claiming so and fail
to initialize libbe. As a consumer, bectl -r (undocumented) can be specified
to op

libbe(3): Handle non-ZFS rootfs better

If rootfs isn't ZFS, current version will emit an error claiming so and fail
to initialize libbe. As a consumer, bectl -r (undocumented) can be specified
to operate on a BE independently of whether on a UFS or ZFS root.

Unbreak this for the UFS case by only erroring out the init if we can't
determine a ZFS dataset for rootfs and no BE root was specified. Consumers
of libbe should take care to ensure that rootfs is non-empty if they're
trying to use it, because this could certainly be the case.

Some check is needed before zfs_path_to_zhandle because it will
unconditionally emit to stderr if the path isn't a ZFS filesystem, which is
unhelpful for our purposes.

This should also unbreak the bectl(8) tests on a UFS root, as is the case in
Jenkins' -test runs.

MFC after: 3 days

show more ...

libbe(3): Properly account for altroot when creating new BEs

Previously we would blindly copy the 'mountpoint' property, which includes
the altroot. The altroot needs to be snipped off prior to sett

libbe(3): Properly account for altroot when creating new BEs

Previously we would blindly copy the 'mountpoint' property, which includes
the altroot. The altroot needs to be snipped off prior to setting it on the
new BE, though, or you'll end up with a new BE and a mountpoint of /mnt with
altroot=/mnt

MFC after: 3 days

show more ...

bectl(3)/libbe(3): Allow BE root to be specified

Add an undocumented -r option preceding the bectl subcommand to specify a BE
root to operate out of. This will remain undocumented for now, as some
c

bectl(3)/libbe(3): Allow BE root to be specified

Add an undocumented -r option preceding the bectl subcommand to specify a BE
root to operate out of. This will remain undocumented for now, as some
caveats apply:

- BEs cannot be activated in the pool that doesn't contain the rootfs
- bectl create cannot work out of the box without the -e option right now,
since it defaults to the rootfs and cross-pool cloning doesn't work like
that (IIRC)

Plumb the BE root through to libbe(3) so that some things -can- be done to
it, e.g.

bectl -r tank/ROOT create -e default upgrade
bectl -r tank/ROOT mount upgrade /mnt

this aides in some upgrade setups where rootfs is not necessarily ZFS, and
also makes it easier/possible to regression-test bectl when combined with a
file-backed zpool.

MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D18029

show more ...