Date: Sun, 10 Mar 2024 23:57:05 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Kirk McKusick <mckusick@mckusick.com> Cc: current@freebsd.org, Mark Millard <marklmi@yahoo.com> Subject: Re: Reason why "nocache" option is not displayed in "mount"? Message-ID: <Ze4ssbRm615OBQA3@kib.kiev.ua> In-Reply-To: <20240310215051.EC14296B7@freefall.freebsd.org> References: <Ze3sMj6jf3upY3_G@kib.kiev.ua> <20240310215051.EC14296B7@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 10, 2024 at 09:50:51PM +0000, Kirk McKusick wrote: > > 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. We are already low on the free bits in the flags, even after expanding them to 64bit. More, there are useful common fs services continuously consuming that flags, e.g. the recent NFS TLS options. I object against using the flags for absolutely not important things, like this nullfs "cache" option. In long term, we would have to export nmount(2) strings since bits in flags are finite, but I prefer to delay it as much as possible.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Ze4ssbRm615OBQA3>