From nobody Tue Jan 30 22:57:20 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 4TPgY12YFgz57ncb for ; Tue, 30 Jan 2024 22:57:25 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPgY10jD6z57Bw; Tue, 30 Jan 2024 22:57:25 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 40UMvLr0096469; Tue, 30 Jan 2024 16:57:21 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1706655442; bh=WjYN3M/+FNFuLebD5OGgANkf8BGLVnrpKxg0aFqGpY0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=k3yJU4+itHLpvWSM4ZMBEh/t8mWS1dJmz4BAhyLCRCPtvWk96CipdClmINPBhPErr KU08Xq1Pwe1yu3DMuPDOhSsMs/mzf04KtroA/6xNuSeAMhOkQW+y4Ly9FBjSRiYFyB gVe1kT2/uC9LuDITtiMjNKmxNxOaqif6GbtCThNK/IRdnsjiRL1jOrdtGgCxRON0vi 3JCvCneNrd4TKhzjSSilpHlBTfdTqAI7yXR4/LFg+2ISpU8qJtD6Xi35Typz3vxJe0 3hsa4JcHRekAudzLoU+1IOvwbFSH2IHQfq+RvHrb032O+2M5H8l93M7zN36KW+Dzgn ATfM2yzShYDfA== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id lAoIJ9F+uWXTeAEAs/W3XQ (envelope-from ); Tue, 30 Jan 2024 16:57:21 -0600 From: Mike Karels To: Cy Schubert Cc: Rick Macklem , Olivier Certner , Warner Losh , freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Tue, 30 Jan 2024 16:57:20 -0600 X-Mailer: MailMate (1.14r6015) Message-ID: <3F6CF45C-3D34-4DA6-9B81-337EB70BB328@karels.net> In-Reply-To: <20240130214811.622C91B0@slippy.cwsent.com> References: <3896441.telDhacX5M@ravel> <1732771.R3xgXyqmLP@ravel> <20240130214811.622C91B0@slippy.cwsent.com> 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 X-Rspamd-Queue-Id: 4TPgY10jD6z57Bw 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)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] On 30 Jan 2024, at 15:48, Cy Schubert wrote: > In message om> > , 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. It looks like automountd already has defaults in place, by class (net, media). The commented-out media line has noatime already, and net may not matter. Our nfs client does not support atime; I don't know about smbfs. Or am I misreading the default auto_master file? Personally, I'm fine with using a different configuration mechanism in automountd. Mike >> >> 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