From nobody Sat Mar 9 19:20:13 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 4TsXvc3nHzz5Dn03 for ; Sat, 9 Mar 2024 19:21:16 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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 ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TsXvb0fTzz4Ndf for ; Sat, 9 Mar 2024 19:21:15 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=xFNEltfD; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1710012061; h=from:from: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:references:references; bh=rAHGvTHA8/MZtMY4YOAVidohL2/5GTvh/cDqaEpW6rk=; b=xFNEltfDE8nSlliXFktpJxz/aebO43TT4WUR6P9CwCp8cCI0ZDXaI5Nj27594c7ZNBhiPM GQ7EBBY5pOLdALh7fwvlUfz6e7Piw1FvbFOIivYAINnPnuritYNFr9qwwVzZaJbTuzMGR6 N0QYvGv56smLvG8ih1qsCoWQQkUZm5QZVOijcMidVzz7uCfZlOHm3yalV7zkcHUEOVXQgk cKcEPaq+PePi+080lg0B/KPOnC8LygdVWlEN8hnyfuKJbnzjbzaMa1o3V10BLHVilmDiYa xQ2ahDi1RLccOhzBjXIJML07UpFABm9lIXFY6P7aBjKLgcMLM4GPBC2WFFlkVg== Date: Sat, 09 Mar 2024 20:20:13 +0100 From: Alexander Leidinger To: Rick Macklem Cc: Warner Losh , Jamie Landeg-Jones , current@freebsd.org Subject: Re: Reason why "nocache" option is not displayed in "mount"? In-Reply-To: References: <09bb45dea82d96c11f34cc48dda540dc@Leidinger.net> <202403072005.427K58KX014923@donotpassgo.dyslexicfish.net> Message-ID: <32d3aed1d5632fbc43b8ec0f083ed90e@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_15e4e632b118ed346b5f64d4ad065209"; micalg=pgp-sha256 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.60 / 15.00]; SIGNED_PGP(-2.00)[]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; HAS_ORG_HEADER(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4TsXvb0fTzz4Ndf This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_15e4e632b118ed346b5f64d4ad065209 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2024-03-09 15:27, schrieb Rick Macklem: > On Sat, Mar 9, 2024 at 5:08 AM Alexander Leidinger > wrote: >> >> Am 2024-03-09 06:07, schrieb Warner Losh: >> >> > On Thu, Mar 7, 2024 at 1:05 PM Jamie Landeg-Jones >> > wrote: >> > >> >> Alexander Leidinger wrote: >> >> >> >>> Hi, >> >>> >> >>> what is the reason why "nocache" is not displayed in the output of >> >>> "mount" for nullfs options? >> >> >> >> Good catch. I also notice that "hidden" is not shown either. >> >> >> >> I guess that as for some time, "nocache" was a "secret" option, no-one >> >> update "mount" to display it? >> > >> > So a couple of things to know. >> > >> > First, there's a list of known options. These are converted to a >> > bitmask. This is then decoded and reported by mount. The other strings >> > are passed to the filesystem directly. They decode it and do things, >> > but they don't export them (that I can find). I believe that's why they >> > aren't reported with 'mount'. There's a couple of other options in >> > /etc/fstab that are pseudo options too. >> >> That's the technical explanation why it doesn't work. I'm a step >> further >> since initial mail, I even had a look at the code and know that >> nocache >> is recorded in a nullfs private flag and that the userland can not >> access this (mount looks at struct statfs which doesn't provide info >> to >> this and some other things). >> >> My question was targeted more in the direction if there is a >> conceptual >> reason or if it was an oversight that it is not displayed. I admit >> that >> this was lost in translation... >> >> Regarding the issue of not being able to see all options which are in >> effect for a given mount point (not specific to nocache): I consider >> this to be a bug. >> Pseudo options like "late" or "noauto" in fstab which don't make sense >> to use when you use mount(8) a FS by hand, I do not consider here. > As a data point, I added the "-m"option to nfsstat(1) so that all the > nfs > related options get displayed. > > Part of the problem is that this will be file system specific, since > nmount() > defers processing options to the file systems. There exists values for a lot of the mount opions which are not displayed. For example the nocache option for nullfs is MNTK_NULL_NOCACHE in https://cgit.freebsd.org/src/tree/sys/sys/mount.h#n515 This may not be useable as is, but I use it to show that there are already bits public about it, just not in the proper place to be useful to the userland. Even FS specific options could be set as part of statfs (by letting the FS set them in struct statfs). Or there could be a per-mount callback / ioctl / whatever which provides the options in some way to the userland if requested. So we either have something which could be used but requires some interface to let a FS set a value somewhere, or if this is a too gross hack, we would need to come up with a new interface to query this info. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_15e4e632b118ed346b5f64d4ad065209 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmXstnwACgkQEg2wmwP4 2IZPrA/8CyBuQDhcEzqqV206Bj9SfWZsObaLtDGdECsaVYcm0GEeqvIRT+DDYpWN QyUOgMPAhJjACSGE2MCqqzINX8aUBQD7VnWnbhwao7coim5fE+UF+ruQ8NTqpSN6 P6Z7RCiuc7T8rvucbZBHc8dyxbj4u5fR62egzL3cgnblIEJzjYxLFrFD9jNFKwYb 8jdKNIMeiQg17cLYkJmm22vESLfnUxx6RKL9O9B0tuY6FoWumMawNg/4RtdSPgCZ FjApQTQw09F977pnB5ZjlpcRTojv/DnCcTWr16NKJO6puY8i5PR4WyZfvQYrxhAg Sj+HgKJRTYv0GR2IceZ1C7B56Y5C4EgOW6E8MljhO6QOYWVdiwsTouHV+kw+zsnC 3F0jm9+y57k8muzhHamfCIOV6duTCFUNsvPrlYww7QxlrcnQoYaTxgRK99qg3/jJ 7o4q7WiVuusVJ9yrkU+JGiq91emKw/U3kXmjvz7RFCn7oXUtWLlE+bOhXymuEj6F UQzOuoz6QVO9EC/wpFmSJXrErVuU+zBR1BxIISAM+wJbjloXimyjqe7m303urexN Lq0oGF1ZVP7p74+SD+9KF7liaE+HRsdBmJNW5C/IqpnpqOp8ir4RiuGftsglE5tP wWf4gpnGShCxf134RmHjoGAttjPFhoxcjDCsxoNi6HNIZo5RxfY= =0Vua -----END PGP SIGNATURE----- --=_15e4e632b118ed346b5f64d4ad065209--