Re: Reason why "nocache" option is not displayed in "mount"?

> Date: Sun, 10 Mar 2024 19:21:54 +0200
> From: Konstantin Belousov <kostikbel@gmail.com>
> To: Kirk McKusick <mckusick@mckusick.com>
> Cc: current@freebsd.org
> Subject: Re: Reason why "nocache" option is not displayed in "mount"?
> 
> 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.

As you note there are some filesystem specific flags already in
mnt_flag that get copied to the statfs f_flags field. My point is
that the NOCACHE flag could be moved to mnt_flag and made visible
in the f_flags field. While it is currently specific to nullfs, it
might be useful to implement it in other filesystems.

	Kirk McKusick