56a7637adb
This patch addresses an issue we recently saw on a production machine: * after booting a ZFS pool failed to get imported (due to an empty /etc/zfs/zpool.cache) * pvestatd/guest-startall eventually tried to import the pool * the pool was imported, yet the datasets of the pool remained not mounted A bit of debugging showed that `zpool import <poolname>` is not atomic, in fact it does fork+exec `mount` with appropriate parameters. If an import ran longer than the hardcoded timeout of 15s, it could happen that the pool got imported, but the zpool command (and its forks) got terminated due to timing out. reproducing this is straight-forward by setting (drastic) bw+iops limits on a guests' disk (which contains a zpool) - e.g.: `qm set 100 -scsi1 wd:vm-100-disk-1,iops_rd=10,iops_rd_max=20,\ iops_wr=15,iops_wr_max=20,mbps_rd=10,mbps_rd_max=15,mbps_wr=10,\ mbps_wr_max=15` afterwards running `timeout 15 zpool import <poolname>` resulted in that situation in the guest on my machine The patch changes the check in activate_storage for the ZFSPoolPlugin, to check if any dataset below the 'pool' (which can also be a sub-dataset) is mounted by parsing /proc/mounts: * this is cheaper than running `zfs get` or `zpool list` * it catches a properly imported and mounted pool in case the root-dataset has 'canmount' set to off (or noauto), as long as any dataset below is mounted After trying to import the pool, we also run `zfs mount -a` (in case another check of /proc/mounts fails). Potential for regression: * running `zfs mount -a` is problematic, if a dataset is manually umounted after booting (without setting 'canmount') * a pool without any mounted dataset (no mountpoint property set and only zvols) - will result in repeated calls to `zfs mount -a` both of the above seem unlikely and should not occur, if using our tooling. Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>