[Bug 249413] bectl - should manipulate canmount on child datasets of the root instead of relying on /etc/rc.d/zfsbe

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sat Sep 19 13:23:51 UTC 2020


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249413

--- Comment #2 from cmh <freebsd at juicer.orange-carb.org> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list