Kirk McKusick <mckusick_at_freebsd.org> wrote on
Date: Sun, 10 Mar 2024 01:53:05 UTC :
> The issue has to do with how flags are defined in mount.h.
> Specifically there are the flags that are externally visible
> (prefixed with MNT_) and those that are for internal use
> (prefixed with MNTK_, the K standing for KERNEL). If it
> is desirable to have MNTK_NULL_NOCACHE visible, then it
> should be renamed to MNT_NULL_CACHE, added to MNT_VISFLAGMASK,
> and listed in MNTOPT_NAMES. It probably belongs in the set
> described as `Flags set by internal operations, but visible
> to the user.' With this change, it will be displayed by
> the mount command and show up in the statfs flags.
-o nocache appears to be mount_nullfs specific: man mount_nullfs
reports:
The options are as follows:
-o Options are specified with a -o flag followed by a comma
separated string of options. See the mount(8) man page for
possible options and their meanings. Additionally the following
option is supported:
nocache
Disable metadata caching in the null layer. Some lower-
layer file systems may force this option. Depending on
the access pattern, this may result in increased lock
contention.
There is also the recent addition to main of:
QUOTE
+The
+.Dv vfs.nullfs.cache_vnodes
+sysctl specifies global default for mount-specific cache/nocache option.
END QUOTE
The vfs.nullfs.cache_vnodes related commits listed a 1 week MFC.
Now -o cache is an option as well, in order to cover both defaults
being possible.
(While it is not limited to what initiated the additions, that
initiation is associated with some ZFS performance problem
avoidance work that is going on where the caching was having
negative consequences when nullfs was also in use.)
kib's wording when I asked about the display-of-mode-status
issue was:
QUOTE
Mount uses getfsstat(2) which has no knowledge of nmount(2).
END QUOTE
===
Mark Millard
marklmi at yahoo.com
