On Sun, Mar 10, 2024 at 01:53:05AM +0000, Kirk McKusick wrote: > 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.
There is no MNTK_NULL_NOCACHE flag in mnt_kern_flags. When userspace communicates the "cache" or "nocache" option to the VFS_MOUNT() op for nullfs, it passes plain C string using the nmount(2) system call. The strings are explicitly queried by nullfs_mount(), mixed with the "default" sysctl, and then the nullfs-mount specific data flag is set, in mp->mnt_data.null_flag. There is no space in the struct statfs for ABI extension. The getfsstat(2) system call cannot report arbitrary fs-specific options. If somebody wants to uniformilly report fs-specific options, instead of scattered fs-specific hacks like MNT_SOFTDEP/MNT_GJOURNAL (UFS) and nfsstat -m (nfsclient), then some extension for nmount(2) is due, say MNT_QUERY_OP, which should be passed down to VFS_MOUNT() and back.
