Date: Sat, 19 Sep 2020 13:23:50 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 249413] bectl - should manipulate canmount on child datasets of the root instead of relying on /etc/rc.d/zfsbe Message-ID: <bug-249413-227-dhRPjP8JuC@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-249413-227@https.bugs.freebsd.org/bugzilla/> References: <bug-249413-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249413 --- Comment #2 from cmh <freebsd@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.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-249413-227-dhRPjP8JuC>