question on zfs canmount vs. zpool import vs. zfs mount

From: Gerrit Kühn <gerrit.kuehn_at_aei.mpg.de>
Date: Mon, 18 Dec 2023 07:59:20 UTC
Hello,

I have a question about the zfs canmount property. Let's suppose a
filesystem like this (simplified):

pool/system1/tank/dir1/dir2
pool/system2/tank/dir1/dir2

I use something like this for backups of systems with (usually more than
one) zfs filesystems. I use syncoid for these backups which recommends
not mounting the filesystems on the backup server due to -F being used
(and indeed this can cause trouble).

So ideally I'd like to set canmount=noauto on the "system/tank" level to
prevent anything beyond if from being mounted on the backup server. This
would also allow to simply create new filesystems (somewhere beyond "tank")
and have them backed up without any further interaction using a recursive
backup strategy.

However, the canmount property is not inherited, and during reboot of the
backup system FreeBSD uses "zpool import -a -N" in rc.d/zpool and "zfs
mount -a" in "rc.d/zfs". This will mount all filesystems at the "dir"
level even when the tank above them is set to "canmount=noauto". The only
way to prevent this is to set all systems on the "dir" level to "noauto".
This is quite tedious and prone-to-error because it has to be done
manually for every new filesystem created on the lower levels.

Interestingly, "zpool import -a" appears to do exactly what I want: it
stops mounting filesystems at the first level that has canmount=noauto
set. It is a bit strange to see that "zfs mount -a" afterwards behaves
differently. Is this intended behaviour?

Is there any clean way to achieve the behaviour I need? I can remove the
"-N" in rc.d/zpool and skip the "zfs mount -a" step in rc.d/zfs to do
this, but patching rc.d scripts is not really a clean solution, either.


cu
  Gerrit