Bug 249413 - bectl - should manipulate canmount on child datasets of the root instead of relying on /etc/rc.d/zfsbe
Summary: bectl - should manipulate canmount on child datasets of the root instead of r...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 11.4-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2020-09-17 23:58 UTC by cmh
Modified: 2020-09-19 13:23 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description cmh 2020-09-17 23:58:12 UTC
bectl uses a counterintuitive and confusing approach to mounting child datasets of the root in boot environments.

The current approach sets all boot environment datasets to canmount=noauto and relies on /etc/rc.d/zfsbe to mount individual child datasets. 

This works, but is unnecessarily opaque and results in unexpected behaviour relative to the normal expectation of zfs filesystem mounting. In addition, the approach requires a specific naming scheme for child datasets (see comments in /etc/rc.d/zfsbe) that appears unnecessary and is undocumented from the perspective of a user trying to use the provided tools without detailed knowledge of the scheme.

I suggest that bectl be modified to set the zfs canmount=on property on the root dataset and all child datasets when activating a boot environment, and set the zfs canmount=noauto property on the root and child datasets of the boot environment that is deactivated. In this arrangement there would be no need for magic behaviour from /etc/rc.d/zfsbe at boot time.

In addition, the current behaviour for child datasets is undocumented in the bectl manpage (which is quite terse) as is the naming scheme requirements in /etc/rc.d/zfsbe. Regardless of the outcome of this bug, bectl needs additional documentation on child datasets of the root, as the process is not fully explained. For example, the significance of the -r flag on 'bectl create' needs to be explained in the context of child datasets of the root.

The discussion at the following forum thread may also be helpful.
Comment 1 Andriy Gapon freebsd_committer 2020-09-18 12:09:36 UTC
I believe that bectl use very good approach to mounting subordinate datasets.

Can you share what you consider to be unnecessarily opaque?
What is unexpected behavior?

Which naming convention, in your opinion, does zfsbe require?
Comment 2 cmh 2020-09-19 13:23:50 UTC
(In reply to Andriy Gapon from comment #1)

Thanks for your questions.

Regarding opacity: ZFS documentation states that canmount=noauto means that the dataset can only be mounted explicitly, not automatically. Therefore, if I do a zfs list -o name,canmount and see that the dataset is set to noauto, I should trust it will not be mounted at boot time. The current FreeBSD approach violates that trust, because an undocumented startup script goes in and manually mounts those filesystems. 

Regarding the naming convention, /etc/rc.d/zfsbe contains a comment stating: "# Handle boot environment subordinate filesystems that may have canmount property set to noauto. For these filesystems mountpoint relative to / must be the same as their dataset name relative to BE root dataset." This is not mentioned in the bectl manpage, nor is the existence of /etc/rc.d/zfsbe mentioned there. Presumably the administrator is supposed to glean all of this without reading the code, but I don't see where or how.

I may be missing something, but it seems to me that this system is unnecessary. bectl is already adjusting the canmount property. It should simply set canmount as documented (i.e. between noauto and on as appropriate) and rely on the normal boottime zfs mounting mechanism. Unless I am misguided here, I think the additional magic script (zfsbe) should be removed as it makes the output of the zfs tools irrelevant and misleading.