From nobody Sun Mar 10 21:57:05 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TtDK51ChQz5Cxx3 for ; Sun, 10 Mar 2024 21:57:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TtDK459vdz4gF1 for ; Sun, 10 Mar 2024 21:57:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 42ALv5GB078877; Sun, 10 Mar 2024 23:57:08 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 42ALv5GB078877 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 42ALv5KN078876; Sun, 10 Mar 2024 23:57:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 Mar 2024 23:57:05 +0200 From: Konstantin Belousov To: Kirk McKusick Cc: current@freebsd.org, Mark Millard Subject: Re: Reason why "nocache" option is not displayed in "mount"? Message-ID: References: <20240310215051.EC14296B7@freefall.freebsd.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240310215051.EC14296B7@freefall.freebsd.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4TtDK459vdz4gF1 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 > > To: Kirk McKusick > > 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.