question on zfs canmount vs. zpool import vs. zfs mount
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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