| 2b908947 | 15-Sep-2019 |
Kyle Evans <[email protected]> |
MFC r352211: bectl(8): Add a "check" command
This command simply returns 0 at the moment and explicitly takes no
arguments. This should be used by utilities wanting to see if bectl can
operate on th
MFC r352211: bectl(8): Add a "check" command
This command simply returns 0 at the moment and explicitly takes no
arguments. This should be used by utilities wanting to see if bectl can
operate on the system they're running, or with a specific root (`bectl -r`).
It may grow more checks than "will libbe successfully init" in the future,
but for now this is enough as that checks for the dataset mounted at "/" and
that it looks capable of being a BE root (e.g. it's not a top-level dataset)
bectl commands can now specify if they want to be silent, and this will turn
off libbe_print_on_error so they can control the output as needed. This is
already used in `bectl check`, and may be turned on in the future for some
other commands where libbe errors are better suppressed as the failure mode
may be obvious.
show more ...
|
| 7bf85780 | 09-Sep-2019 |
Kyle Evans <[email protected]> |
Back out r352087 for now
The ancient-gcc -Wno-error series hasn't been MFC'd yet to this branch and
some GCC builds seem to have raised a false-positive that wasn't caught due
to -Wno-error on head.
Back out r352087 for now
The ancient-gcc -Wno-error series hasn't been MFC'd yet to this branch and
some GCC builds seem to have raised a false-positive that wasn't caught due
to -Wno-error on head. Back it out for now, will reapply when r352092
becomes eligible for MFC...
show more ...
|
| f32c3b2e | 09-Sep-2019 |
Kyle Evans <[email protected]> |
MFC r351813: bectl(8): implement sorting for 'bectl list' output
Allow 'bectl list' to sort output by a given property name. The property
name is passed in using a command-line flag, '-c' for ascend
MFC r351813: bectl(8): implement sorting for 'bectl list' output
Allow 'bectl list' to sort output by a given property name. The property
name is passed in using a command-line flag, '-c' for ascending order and
'-C' for descending order. The properties allowed to sort by are:
- name (the default output, even if '-c' or '-C' are not used)
- creation
- origin
- used
- usedds
- usedsnap
- usedrefreserv
The default output for 'bectl list' is now ascending alphabetical order of
BE name.
To sort by creation time from earliest to latest, the command would be
'bectl list -c creation'
show more ...
|
| 686d5664 | 26-Jul-2019 |
Kyle Evans <[email protected]> |
MFC r349380, r349383, r349455: bectl(8)/libbe(3) fixes
r349380:
libbe(3): mount: the BE dataset is mounted at /
Other parts of libbe(3) were fairly strict on the mountpoint property of the
BE datas
MFC r349380, r349383, r349455: bectl(8)/libbe(3) fixes
r349380:
libbe(3): mount: the BE dataset is mounted at /
Other parts of libbe(3) were fairly strict on the mountpoint property of the
BE dataset, and be_mount was not much better. It was improved in r347027 to
allow mountpoint=none for depth==0, but this bit was still sensitive to
mountpoint != / and mountpoint != none. Given that other parts of libbe(3)
no longer restrict the mountpoint property here, and the rest of the base
system is generally OK and will assume that a BE is mounted at /, let's do
the same.
r349383:
libbe(3): restructure be_mount, skip canmount check for BE dataset
Further cleanup after r349380; loader and kernel will both ignore canmount
on the root dataset as well, so we should not be so strict about it when
mounting it. be_mount is restructured to make it more clear that depth==0 is
special, and to not try fetching these properties that we won't care about.
r349455:
bectl(8): create non-recursive boot environments
bectl advertises that it has the ability to create recursive and
non-recursive boot environments. This patch implements that functionality
using the be_create_depth API provided by libbe. With this patch, bectl now
works as bectl(8) describes in regards to creating recursive/non-recursive
boot environments.
show more ...
|
| 6f003a7a | 27-May-2019 |
Kyle Evans <[email protected]> |
MFC r348215, r348219: fix bectl(8) jail w/ numeric BE names
r348215:
jail_getid(3): validate jid string input
Currently, if jail_getid(3) is passed in a numeric string, it assumes that
this is a ji
MFC r348215, r348219: fix bectl(8) jail w/ numeric BE names
r348215:
jail_getid(3): validate jid string input
Currently, if jail_getid(3) is passed in a numeric string, it assumes that
this is a jid string and passes it back converted to an int without checking
that it's a valid/existing jid. This breaks consumers that might use
jail_getid(3) to see if it can trivially grab a jid from a name if that name
happens to be numeric but not actually the name/jid of the jail. Instead of
returning -1 for the jail not existing, it'll return the int version of the
input and the consumer will not fallback to trying other methods.
Pass the numeric input to jail_get(2) as the jid for validation, rather than
the name. This works well- the kernel enforces that jid=name if name is
numeric, so doing the safe thing and checking numeric input as a jid will
still DTRT based on the description of jail_getid.
r348219:
bectl(8): Add a test for jail/unjail of numeric BE names
Fixed by r348215, bectl ujail first attempts the trivial fetch of a jid by
passing the first argument to 'ujail' to jail_getid(3) in case a jid/name
have been passed in instead of a BE name. For numerically named BEs, this
was doing the wrong thing: instead of failing to locate the jid specified
and falling back to mountpath search, jail_getid(3) would return the input
as-is.
While here, I've fixed bectl_jail_cleanup which still used a hard-coded pool
name that was overlooked w.r.t. other work that was in-flight around the
same time.
show more ...
|
| fa88eafa | 08-Apr-2019 |
Kyle Evans <[email protected]> |
MFC r343335, r343977, r343993-r343994, r344034, r344084, r345302, r345769
r343335:
libbe(3): simplify import, allow replication streams
Previously, we directly used libzfs_core's lzc_receive to imp
MFC r343335, r343977, r343993-r343994, r344034, r344084, r345302, r345769
r343335:
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.
r343977:
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.
r343993:
bectl(8): Add -o flag to destroy to clean up the origin snapshot of BE
We can't predict when destruction of origin is needed, and currently we have
a precedent for not prompting for things. Leave the decision up to the user
of bectl(8) if they want the origin snapshot to be destroyed or not.
Emits a warning when -o isn't used and an origin snapshot is left to be
cleaned up, for the time being. This is handy when one drops the -o flag but
really did want to clean up the origin.
A couple of -e ignore's have been sprinkled around the test suite for places
that we don't care that the origin's not been cleaned up. -o functionality
tests will be added in the future, but are omitted for now to reduce
conflicts with work in flight to fix bits of the tests.
r343994:
bectl(8): commit missing test modifications from r343993
r344034:
libbe(3): Belatedly note the BE_DESTROY_ORIGIN option added in r343977
r344084:
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.
r345302:
bectl(8): change jail command to execute jail(8)
The jail(8) command provides a variety of jail pseudo-parameters that are
useful to consumers of bectl, mount.devfs being the most-often-requested
paramater by bectl users.
command, exec.start, nopersist, and persist may not be specified via -o to
bectl. The command/exec.start remains passed as it always has at the end of
bectl, and persistence is dictated by -b/-U bectl jail arguments.
r345769:
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
show more ...
|
| d81df689 | 23-Aug-2018 |
Kyle Evans <[email protected]> |
bectl(8): Man page and usage cleanup
- Some overly-long lines
- Consistently using .Brq ({})
- Consistently using .Cm
- Not using .Ao/.Ac around .Ar
PR: 230576
Submitted by: Yuri Pankov (with a fa
bectl(8): Man page and usage cleanup
- Some overly-long lines
- Consistently using .Brq ({})
- Consistently using .Cm
- Not using .Ao/.Ac around .Ar
PR: 230576
Submitted by: Yuri Pankov (with a fair amount of rebasing pre-commit)
show more ...
|