Date: Thu, 3 Jul 2025 07:24:07 -0700 From: Rick Macklem <rick.macklem@gmail.com> To: Olivier Certner <olce@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-current@freebsd.org Subject: Re: RFC: checking file systems support UF_HIDDEN, UF_SYSTEM Message-ID: <CAM5tNy6Xqkh58muE0xymztmN9ZTzxTDm23oX-hTcdKeshz4hBg@mail.gmail.com> In-Reply-To: <2410567.gG0HsuGxDd@ravel> References: <CAM5tNy5eoY5f-fo9BKc4v34XKXF6%2B6Ae7Zpq=FH7owaSRYSHmw@mail.gmail.com> <4214798.O2WMGSuNBG@ravel> <aGZSh4rvXfLbnG-3@kib.kiev.ua> <2410567.gG0HsuGxDd@ravel>
index | next in thread | previous in thread | raw e-mail
On Thu, Jul 3, 2025 at 4:01 AM Olivier Certner <olce@freebsd.org> wrote: > > > It is not the right usage of the MNT_ flags. They are for feature > > controlling, not for the feature reporting. > > That is not the case today (MNT_LOCAL, MNT_QUOTA, MNT_ROOTFS, MNT_USER, etc.). I also would like this to become true at some point. > > > VOP_PATHCONF() is exactly for reporting some mnt features. > > No, it is to report features that depend on a path. It can be (ab)used to report mount features (calling it on any file inside the mount), but that obfuscates the fact that an information is per-mount, whereas statfs()/statvfs() are exactly designed for per-mount information. Note that, for a NFSv4 client mount, support for hidden/system could change somewhere in the mounted server tree, since for NFSv4 the tree can consist of multiple file systems of different types. For example: If an ext2 fs was mounted under a ufs file system, the hidden/system support would go away when the mount point is crossed into the ext2 subtree. So, I think pathconf is the best way to go (and avoids using up flag bits). rick > > > Also, this namespace should not be used frivolously, we already had to > > extend flags to 64bit, and again we are not too far from exhausting it. > > I don't disagree. That said, at some point, we'll have to dodge the bullet, including separating control flags from report ones in the MNT_* namespace (and provide compat' functionality), and probably extending control flags with a second 64-bit field. > > I suspected from the start that that was the main reason behind you recommending VOP_PATHCONF(). My point here is that it is a slightly non-optimal design choice (as explained just above) that will stay and was made out of a practical issue that anyway will have to be solved at some point, and I find this a bit unfortunate. Solving the issue now is certainly much more work, and in any case I didn't mean to object to not doing it now. But if someone(tm) wants to do it now, that would be great (perhaps me, but not sure yet). > > Regards. > > -- > Olivier Certnerhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy6Xqkh58muE0xymztmN9ZTzxTDm23oX-hTcdKeshz4hBg>