From nobody Tue Jan 30 21:48:11 2024 X-Original-To: freebsd-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 4TPf1C2WJPz57gFK for ; Tue, 30 Jan 2024 21:48:15 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPf1B3DZHz4y3p; Tue, 30 Jan 2024 21:48:14 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTPS id UtE1r6OLRGAIJUvxlrCV7L; Tue, 30 Jan 2024 21:48:13 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id UvxjrXz0EWhyfUvxkrBoJZ; Tue, 30 Jan 2024 21:48:13 +0000 X-Authority-Analysis: v=2.4 cv=MenPuI/f c=1 sm=1 tr=0 ts=65b96e9d a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=dEuoMetlWLkA:10 a=1QTDH3R-AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=YwoGRumlfV3EDiC4sgoA:9 a=CjuIK1q_8ugA:10 a=A7PbjfUNzwAiWwc5k9lq:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 6DCA81299; Tue, 30 Jan 2024 13:48:11 -0800 (PST) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 622C91B0; Tue, 30 Jan 2024 13:48:11 -0800 (PST) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Rick Macklem cc: Mike Karels , Olivier Certner , Warner Losh , freebsd-current@freebsd.org Subject: Re: noatime on ufs2 In-reply-to: References: <3896441.telDhacX5M@ravel> <1732771.R3xgXyqmLP@ravel> Comments: In-reply-to Rick Macklem message dated "Tue, 30 Jan 2024 13:12:34 -0800." 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 Date: Tue, 30 Jan 2024 13:48:11 -0800 Message-Id: <20240130214811.622C91B0@slippy.cwsent.com> X-CMAE-Envelope: MS4xfERAhZeBN+oZ3etkJuVLGbH9JwfMqonlDpy8N3gqTuz51ZORxcnIMhnD3aOcUFOTAdwm2Y/YD3cmcxMS1EOTeEoGWXFEFuoc3dBQtMcDUeMYnJTar37n Rfm7vdqFB8/VqFNHjRvn5ea+5UKEllnHm6x6BFVNRuFXZXJg1h1aOr+F89UQSPlf+BH7CXWamVw9mXhTOCBbrcsr2uSET0k70+CDA7Y3EIw6IFA9tabJWRqV breopdTW6xl0pjRKC0Ol4c/M1Q086TiIfvE2LHDYe74i7+4zVlTIhbjuvj3nCDWz9kKqJ7bXnNamIH2S9B2gmg== X-Spamd-Bar: / X-Spamd-Result: default: False [-0.18 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.980]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.33:from]; RCVD_COUNT_THREE(0.00)[4]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[cschubert.com]; ARC_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TAGGED_RCPT(0.00)[]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4TPf1B3DZHz4y3p In message , Rick Macklem writes: > On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels wrot= > e: > > > > On 30 Jan 2024, at 3:00, Olivier Certner wrote: > > > > > Hi Warner, > > > > > >> I strongly oppose this notion to control this from loader.conf. Root i= > s > > >> mounted read-only, so it doesn't matter. That's why I liked Mike's > > >> suggestion: root isn't special. > > > > > > Then in fact there is nothing to oppose. You've just said yourself tha= > t root is mounted first read-only. As Mike already said, it is remounted r= > /w in userland later in the boot process. I just re-checked the code, beca= > use I only had a vague recollection of all this, and can confirm. > > > > > > I mentioned the need to modify '/etc/loader.conf' as a possible consequ= > ence, not as a goal. Given what we have established, there is no need to c= > hange it at all. > > > > > > The root FS is thus in no way more special in the sysctl proposal than = > with Mike's (assuming it doesn't rely on sysctl), this is an independent pr= > operty due to the boot process design. > > > > With the possible exception that the sysctl mechanism might then have to > > apply to mount update. > > > > >>>> It also seems undesirable to add a sysctl to control a value that th= > e > > >>>> kernel doesn't use. > > >>> > > >>> The kernel has to use it to guarantee some uniform behavior irrespect= > ive > > >>> of the mount being performed through mount(8) or by a direct call to > > >>> nmount(2). I think this consistency is important. Perhaps all > > >>> auto-mounters and mount helpers always run mount(8) and never deal wi= > th > > >>> nmount(2), I would have to check (I seem to remember that, a long tim= > e ago, > > >>> when nmount(2) was introduced as an enhancement over mount(2), the st= > ance > > >>> was that applications should use mount(8) and not nmount(2) directly)= > . > > >>> Even if there were no obvious callers of nmount(2), I would be a bit > > >>> uncomfortable with this discrepancy in behavior. > > > > Based on a quick git grep, it looks like most of the things in base use > > nmount(2), not mount(2). If they use mount(8), then it's not a problem > > because mount(8) would be the first thing to get things right. If, by > > mount helpers, you mean things like mount_nfs and mount_mfs, then mount(8= > ) > > uses them rather than the reverse. I also don't remember any admonition > > not to use nmount(2). mount(8) has a limited set of file system types th= > at > > it handles directly. > > > > >> I disagree. I think Mike's suggestion was better and dealt with POLA a= > nd > > >> POLA breaking in a sane way. If the default is applied universally in = > user > > >> space, then we need not change the kernel at all. > > > > > > I think applying the changes to userland only is really a bad idea. I'= > ve already explained why, but going to do it again in case you missed that.= > If you have counter-arguments, fine, but I would like to see them. > > > > > > Changing userland only causes a discrepancy between mount(8) and nmount= > (2). Even if the project would take a stance that nmount(2) is not a publi= > c API and mount(8) must always be used, the system call will still be there= > And if it's not supposed to be used, what's the problem with changing it= > as well? > > > > I don't think that stance has been taken; nmount(2) is certainly document= > ed. > > But I think that user level changes are required in both cases. First, f= > or > > the kernel to do the right thing, it needs to know if either noatime or a= > time > > has been specified explicitly, or if the default should apply. Otherwise= > , the > > kernel can only force noatime to be used in all cases or none, which I be= > lieve > > is a non-starter. Second, for anything using mount(2), the flags include= > only > > MNT_NOATIME, which can only include two options, not the required three. = > It > > would be possible to add another flag meaning to actually use the state o= > f the > > MNT_NOATIME flag, but that would require user-level changes. Third, if I > > understand correctly, mount(8) parses the options and condenses the stand= > ard > > boolean options like {,no}atime into a bit, preserving the last option > > specified. E.g. if the fstab lists noatime for a file system, and "mount= > -o > > atime ..." is given on the command line, noatime will not be included in > > the kernel options. The kernel can't tell why, whether nothing was speci= > fied > > or the option was explicit. In theory, three states can be encoded using > > nmount; options could include "atime", "noatime", or neither. But that's > > not what the current user level does, so changes are required. Given tha= > t, > > it makes the most sense to have mount(8) and others to incorporate the > > default into their operation, and just give the kernel the answer. btw, > > see mntopts(3) for where this code would go. > These days most mount options are parsed in the kernel via vfs_getopts(), > but not "atime". It appears that "(no)atime" sets/clears MNT_NOATIME in > userspace via the getmntopts() function that lives in > /usr/src/sbin/mount/getmntopts.c. > > I think this is mostly cruft left over from the mount(2)->nmount(2) convers= > ion, > for generic options that cover all file systems. > > Personally, I like the idea of the addition of a defaults line in > fstab(5), but am > not sure what needs to be done for things like auto mounting? automountd will require addition of of options to existing configuration. am-utils users can add a default line. Or an addition of a "default" specification, which would make it incompatible with Linux and Solaris. Currently our autofs is 100% compatible (minus the /net bug) with both. > > I'll admit I do not see what the default value of "(no)atime" is, so long a= > s it > can be overridden on a per mount basis. A change to what the installer sets= > , > seems fine to me. > > rick > [...] -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0