From nobody Sun Mar 10 21:50:51 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 4TtD9m15jyz5Cx9W for ; Sun, 10 Mar 2024 21:50:52 +0000 (UTC) (envelope-from mckusick@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TtD9m0h2fz4fK0; Sun, 10 Mar 2024 21:50:52 +0000 (UTC) (envelope-from mckusick@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1710107452; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to; bh=PbxJCuRdX1dUm9Ep2v6jZkr7vBjwjIqDJ8aihWjEhpY=; b=XPbiGMMlGZo1kbop762siWOZQYQeqLNrSDf5csfKOXP1lT9CGG0UZr4+unLZ/B45VVFt6N rDwD7foHEXU7+7yNBzFAHVdVSFVM1EF3DTAI6pUz+WaruPSSHzu8jZAl3kBP5gRknPQOnl CYRFW3QiRh/jEW8xGmfM8C7G1lHGilafMF0JSvHzcR4fq5MpNwRx25nLfqQ6bVBIkFX4t6 f1kH53rD6UTlY2QH6a8cwPcpZq69WHBuRx0GqeqrqC1TRtNCKfqixxlizuc596kp2SATHI PjYSMSkG8tqy0yVSiLeifYQzDXkcjQFjwyxcU+fgUxkGnOT+yH0oXorVCTNEWw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1710107452; a=rsa-sha256; cv=none; b=mGb9PScoat7hlYpkOJU0KsgIwUCEHjUEpw13OMRDQ8XPKmnZmJGiqZoGksSgPgjp3eJII0 4pN6/0UXUSiwmkal05b7Gal3HTCvVuHCfN09e6qY4j5tF0TAZawHV6sM+NFYoCYUNii829 H6WKClKDx5RoKxmwv0fth5Su6dPyEqZ7wppdG4HOpCS2umcnM+L9Udc/q+PkBBo3wxVdjE i2noLqwYh9iJyZ1k9Jjd4E73YB4ze0RWWPLX0rWFOHkEQdKCTHp3OA0yfUD8KofdCrLzhm NcGqX1Sl5V5TRT3faO8E9zvfRe6iNYhcmR8kzJhKUdnBsE45QVZV9ZYpujrQpA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1710107452; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to; bh=PbxJCuRdX1dUm9Ep2v6jZkr7vBjwjIqDJ8aihWjEhpY=; b=wYQlMzmwdOvPJTCFEFmLDL8XoSMN/JIyhbqojSUjbGHM31kZsiyPGmx1qj6hB5mmuW1VAx ChydzHqbaMRV+eHm1wBHWSjb/LpeM6IEVUnr/8ho6A2wI3Z2ADQM7HskxD7JcDti8EyxVv i/l/OHN/KznsFwHoiH9ayMrVxPSu8pQhlE6CNy4yZdDdyMkockyONAJWutUUGGpMoKxc1A SGQaKaIdYNOf4OKp0q0gBN6CwkbLr9r3hLPhLHxNKThP9EWrcCeJUYIBA7PuPSadtIgoJl A38fptp5pKhXnUxMN7uYawcqWD+S3MnkCvKiLoKJxc04/TVfKHcja0bgnzFgdw== Received: by freefall.freebsd.org (Postfix, from userid 740) id EC14296B7; Sun, 10 Mar 2024 21:50:51 +0000 (UTC) From: Kirk McKusick To: Konstantin Belousov Subject: Re: Reason why "nocache" option is not displayed in "mount"? cc: current@freebsd.org, Mark Millard Reply-To: Kirk McKusick In-reply-to: Comments: In-reply-to Konstantin Belousov message dated "Sun, 10 Mar 2024 19:21:54 +0200." 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-ID: <70117.1710107451.1@freefall.freebsd.org> Date: Sun, 10 Mar 2024 21:50:51 +0000 Message-Id: <20240310215051.EC14296B7@freefall.freebsd.org> > 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. Kirk McKusick