# Boot environments with empty child datasets



## mickey (Feb 21, 2019)

Today I was playing with reorganising the layout of my boot environments. As I use BEs mostly for OS updates, I like to have each BE to have it's own version of the FreeBSD source tree included. Also splitting off /usr/local from the base system seems logical. What I don't want is to have /usr separated because when you boot into single-user mode it then does not get mounted automatically, and that's more hassle and error-prone than having any real benefit. So what I would like to have is an empty /usr dataset with canmount=off, whose sole purpose is to contain child datasets and have those inherit the mountpoint property, something like this:

```
Dataset:                                Canmount:       Mountpoint:
--------------------------------------------------------------------------
sys/ROOT/R12.0                          noauto          /
sys/ROOT/R12.0/usr                      off             /usr       (inherited from R12.0)
sys/ROOT/R12.0/usr/src                  noauto          /usr/src   (inherited from R12.0)
sys/ROOT/R12.0/usr/local                noauto          /usr/local (inherited from R12.0)
```
So far, so good, booting into the BE works just as expected. Unfortunately neither bectl(8) nor beadm(1) respect the canmount=off property on the /usr dataset when creating a new boot environment based off the current one. Creating a new BE using `bectl create test` sets the canmount property of the /usr dataset in the newly created BE to noauto:

```
Dataset:                                Canmount:       Mountpoint:
--------------------------------------------------------------------------
sys/ROOT/test                           noauto          /
sys/ROOT/test/usr                       noauto          /usr (inherited)
sys/ROOT/test/usr/src                   noauto          /usr/src (inherited)
sys/ROOT/test/usr/local                 noauto          /usr/local (inherited)
```
Activating the new BE using `bectl activate test` does not change any of the canmount properties, they all stay at noauto. If you now try to boot into the new BE you will encounter one problem. You get an empty /usr filesystem mounted, not so good. Additionally, after reactivating the original BE with `bectl activate R12.0` and dumping the test BE using `bectl destroy test`, the snapshots that were used for creating the test BE are left behind, also not so good.

Creating a new BE using `beadm create honk` behaves a little different in that it sets the canmount property of all datasets within the newly created BE to off:

```
Dataset:                                Canmount:       Mountpoint:
--------------------------------------------------------------------------
sys/ROOT/honk                           off             /
sys/ROOT/honk/usr                       off             /usr (inherited)
sys/ROOT/honk/usr/src                   off             /usr/src (inherited)
sys/ROOT/honk/usr/local                 off             /usr/local (inherited)
```
Activating the new BE using `beadm activate honk` sets all canmount properties from off to noauto, effectively giving the same result when trying to boot into the new BE as with bectl(8). Reactivating the original BE using `beadm activate R12.0` for some reason sets all canmount properties of the original BE to on, including the /usr dataset which was explicitly set to off before. This seems strange, yet sysutils/beadm(1) gets bonus points for not leaving behind any snapshots after having dumped the test BE using `beadm destroy honk`. 

So my impression is that right now neither bectl(8) nor beadm(1) are designed to handle the case of intentionally empty datasets within a BE that are not meant to ever get mounted. In order to solve the problem I could either split off the /usr filesystem so that it causes no harm when it gets mounted or to go without the empty intermediate /usr dataset and set explicit mountpoints for the /usr/src and /usr/local datasets. The former I don't really like to do for abovementioned reasons, the latter just looks sick and breaks the inheritance of mountpoints. I would kindly embrace it if those tools were able to handle this kind of situation, but that's of course not up for me to decide. 

I would like to hear other people's opinions on that matter. Is it cause I is alien, even wanting to have such a BE layout in the first place, or ... ?


----------

