aboutsummaryrefslogtreecommitdiffstats
path: root/module/os
diff options
context:
space:
mode:
authorAlan Somers <[email protected]>2021-06-08 07:36:43 -0600
committerGitHub <[email protected]>2021-06-08 07:36:43 -0600
commit75b4cbf62590c23fac3667537961a2a75fdc2cc3 (patch)
tree5342f2f799f04d3ded61148bec22e835ca916b2c /module/os
parent9685f363c32a4c590e76fa7ff6152bafd36a4d7c (diff)
libzfs: On FreeBSD, use MNT_NOWAIT with getfsstat
`getfsstat(2)` is used to retrieve the list of mounted file systems, which libzfs uses when fetching properties like mountpoint, atime, setuid, etc. The `mode` parameter may be `MNT_NOWAIT`, which uses information in the VFS's cache, or `MNT_WAIT`, which effectively does a `statfs` on every single mounted file system in order to fetch the most up-to-date information. As far as I can tell, the only fields that libzfs cares about are the filesystem's name, mountpoint, fstypename, and mount flags. Those things are always updated on mount and unmount, so they will always be accurate in the VFS's mount cache except in two circumstances: 1) When a file system is busy unmounting 2) When a ZFS file system changes the value of a mount-overridable property like atime or setuid, but doesn't remount the file system. Right now that only happens when the property is changed by an unprivileged user who has delegated authority to change the property but not to mount the dataset. But perhaps libzfs could choose to do it for other reasons in the future. Switching to `MNT_NOWAIT` will greatly improve speed with no downside, as long as we explicitly update the mount cache whenever we change a mount-overridable property. For comparison, Illumos gets this information using the native `getmntany` and `getmntent` functions, which also use cached information. The illumos function that would refresh the cache, `resetmnttab`, is never called by libzfs. And on GNU/Linux, `getmntany` and `getmntent` don't even communicate with the kernel directly. They simply parse the file they are given, which is usually /etc/mtab or /proc/mounts. Perhaps the implementation of /proc/mounts is synchronous, ala MNT_WAIT; I don't know. Sponsored-by: Axcient Reviewed-by: Ryan Moeller <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Alan Somers <[email protected]> Closes: #12091
Diffstat (limited to 'module/os')
-rw-r--r--module/os/freebsd/zfs/zfs_ioctl_os.c17
-rw-r--r--module/os/linux/zfs/zfs_ioctl_os.c6
2 files changed, 23 insertions, 0 deletions
diff --git a/module/os/freebsd/zfs/zfs_ioctl_os.c b/module/os/freebsd/zfs/zfs_ioctl_os.c
index 0e0c16033..7f7e2b72c 100644
--- a/module/os/freebsd/zfs/zfs_ioctl_os.c
+++ b/module/os/freebsd/zfs/zfs_ioctl_os.c
@@ -138,6 +138,23 @@ zfs_ioc_nextboot(const char *unused, nvlist_t *innvl, nvlist_t *outnvl)
return (error);
}
+/* Update the VFS's cache of mountpoint properties */
+void
+zfs_ioctl_update_mount_cache(const char *dsname)
+{
+ zfsvfs_t *zfsvfs;
+
+ if (getzfsvfs(dsname, &zfsvfs) == 0) {
+ struct mount *mp = zfsvfs->z_vfs;
+ VFS_STATFS(mp, &mp->mnt_stat);
+ zfs_vfs_rele(zfsvfs);
+ }
+ /*
+ * Ignore errors; we can't do anything useful if either getzfsvfs or
+ * VFS_STATFS fails.
+ */
+}
+
uint64_t
zfs_max_nvlist_src_size_os(void)
{
diff --git a/module/os/linux/zfs/zfs_ioctl_os.c b/module/os/linux/zfs/zfs_ioctl_os.c
index b9fcaaad7..fee3fe540 100644
--- a/module/os/linux/zfs/zfs_ioctl_os.c
+++ b/module/os/linux/zfs/zfs_ioctl_os.c
@@ -157,6 +157,12 @@ zfs_max_nvlist_src_size_os(void)
return (MIN(ptob(zfs_totalram_pages) / 4, 128 * 1024 * 1024));
}
+/* Update the VFS's cache of mountpoint properties */
+void
+zfs_ioctl_update_mount_cache(const char *dsname)
+{
+}
+
void
zfs_ioctl_init_os(void)
{