From nobody Wed Jan 31 14:03:03 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 4TQ3fK42Vhz58bHl for ; Wed, 31 Jan 2024 14:03:21 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQ3fK1fmtz4nWh; Wed, 31 Jan 2024 14:03:21 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-6dfb9594cd9so992038b3a.2; Wed, 31 Jan 2024 06:03:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706709799; x=1707314599; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=aLuj6U45mG7cbkdmCG3WgDWqNm/0AJW9HXDDtiYP5Nc=; b=V1Q8VfaSuXHhRJPXPkzc0QhgrNDQKbbe9U0yjXCpkNc+yejRL2am2vN4wzXUxFYjSB 46Q141q8/IVwZAe4xpRrlwDLSmACyQv6oi8zyUUDrgGOuL3YJKh1fsESJeowIHEcsAW3 nIqw/+dbLP2+DqzxeYERWQxw5WZ/2FVvHJ/wKxDHSR7MnaWteVoeqR6eg8AEyhZWATq4 8kMil+tm9mcMMNPGNxZumfvf2znfBj85Vog/v+vGsG2ozSzMcPOROqGaAzXKDNQchB/R evzOmeO4/j7Nhz2Wqguvj5GrQvVI1so6MacxMrvOlBRD6Z7fbZFTuWRiEViD7l+Ekqgf 6vcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706709799; x=1707314599; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aLuj6U45mG7cbkdmCG3WgDWqNm/0AJW9HXDDtiYP5Nc=; b=HLigD2GjcZp4gKvU/ou9j2Gf7LGxw+OGJOho01MoZ24kUdj5Ocr5GdsSCiq8emn63/ GTD4iRuFxMKrJ/kTHN4gCEVIlZ9fS6+a+QoKYP1y2Xi8bEZYelUWh5Un4+VJiTTeHHbI 7476OTpv7ZZwzCSDYXY5WvifBjgSmbjTD2hSI7O4jvVDgz0fXaagWdLeXjL2OxeCyNQt zMZCBjoZMQamKOR6HpW/HUb+l+yqab6yS/HqbBcAgnq3m4aKkqclPweEATkYTOTP1uBH SdWJOMWLkmivvySNsgFRsHeGMVWA95nYbIoqeTPhZW+RzEhl2wwmaM5ALLa9ktUEqZy5 S4RQ== X-Gm-Message-State: AOJu0YwweZkMzBKJA94QEftYqlV4lu1va5XDe+WGdmhJq1Y+wtZ0PaLO W0XCaKgqwQHdG0j06/s5Tnm5F67Z0zmgNm0/jAsN3YANUwmd2H+ilxvHvi8UcW4JWE0OVklWBFD FrXXWF+MzEC6pHdv6MnRZioY5zod6NV0= X-Google-Smtp-Source: AGHT+IGwJHyecNF+FptAdhlrHAw1642B7NEeQSU/pxf90UbZ++nA4WAuavlSsjKrhxwQYs6PoB0HaXwtjBm/e1gnxM8= X-Received: by 2002:aa7:8110:0:b0:6de:4da:72c6 with SMTP id b16-20020aa78110000000b006de04da72c6mr1683871pfi.9.1706709799132; Wed, 31 Jan 2024 06:03:19 -0800 (PST) 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 References: <3896441.telDhacX5M@ravel> <1732771.R3xgXyqmLP@ravel> <20240130214811.622C91B0@slippy.cwsent.com> <3F6CF45C-3D34-4DA6-9B81-337EB70BB328@karels.net> In-Reply-To: <3F6CF45C-3D34-4DA6-9B81-337EB70BB328@karels.net> From: Rick Macklem Date: Wed, 31 Jan 2024 06:03:03 -0800 Message-ID: Subject: Re: noatime on ufs2 To: Mike Karels Cc: Cy Schubert , Olivier Certner , Warner Losh , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TQ3fK1fmtz4nWh 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_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] On Tue, Jan 30, 2024 at 2:57=E2=80=AFPM Mike Karels wrote= : > > On 30 Jan 2024, at 15:48, Cy Schubert wrote: > > > In message > om> > > , Rick Macklem writes: > >> On Tue, Jan 30, 2024 at 10:49=3DE2=3D80=3DAFAM Mike Karels wrot=3D > >> e: > >>> > >>> On 30 Jan 2024, at 3:00, Olivier Certner wrote: > >>> > >>>> Hi Warner, > >>>> > >>>>> I strongly oppose this notion to control this from loader.conf. Roo= t i=3D > >> 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=3D > >> t root is mounted first read-only. As Mike already said, it is remoun= ted r=3D > >> /w in userland later in the boot process. I just re-checked the code,= beca=3D > >> 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 cons= equ=3D > >> ence, not as a goal. Given what we have established, there is no need= to c=3D > >> hange it at all. > >>>> > >>>> The root FS is thus in no way more special in the sysctl proposal th= an =3D > >> with Mike's (assuming it doesn't rely on sysctl), this is an independe= nt pr=3D > >> 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=3D > >> e > >>>>>>> kernel doesn't use. > >>>>>> > >>>>>> The kernel has to use it to guarantee some uniform behavior irresp= ect=3D > >> 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=3D > >> th > >>>>>> nmount(2), I would have to check (I seem to remember that, a long = tim=3D > >> e ago, > >>>>>> when nmount(2) was introduced as an enhancement over mount(2), the= st=3D > >> ance > >>>>>> was that applications should use mount(8) and not nmount(2) direct= ly)=3D > >> . > >>>>>> Even if there were no obvious callers of nmount(2), I would be a b= it > >>>>>> uncomfortable with this discrepancy in behavior. > >>> > >>> Based on a quick git grep, it looks like most of the things in base u= se > >>> nmount(2), not mount(2). If they use mount(8), then it's not a probl= em > >>> because mount(8) would be the first thing to get things right. If, b= y > >>> mount helpers, you mean things like mount_nfs and mount_mfs, then mou= nt(8=3D > >> ) > >>> uses them rather than the reverse. I also don't remember any admonit= ion > >>> not to use nmount(2). mount(8) has a limited set of file system type= s th=3D > >> at > >>> it handles directly. > >>> > >>>>> I disagree. I think Mike's suggestion was better and dealt with POL= A a=3D > >> nd > >>>>> POLA breaking in a sane way. If the default is applied universally = in =3D > >> 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'=3D > >> ve already explained why, but going to do it again in case you missed = that.=3D > >> If you have counter-arguments, fine, but I would like to see them. > >>>> > >>>> Changing userland only causes a discrepancy between mount(8) and nmo= unt=3D > >> (2). Even if the project would take a stance that nmount(2) is not a = publi=3D > >> c API and mount(8) must always be used, the system call will still be = there=3D > >> And if it's not supposed to be used, what's the problem with changin= g it=3D > >> as well? > >>> > >>> I don't think that stance has been taken; nmount(2) is certainly docu= ment=3D > >> ed. > >>> But I think that user level changes are required in both cases. Firs= t, f=3D > >> or > >>> the kernel to do the right thing, it needs to know if either noatime = or a=3D > >> time > >>> has been specified explicitly, or if the default should apply. Other= wise=3D > >> , the > >>> kernel can only force noatime to be used in all cases or none, which = I be=3D > >> lieve > >>> is a non-starter. Second, for anything using mount(2), the flags inc= lude=3D > >> only > >>> MNT_NOATIME, which can only include two options, not the required thr= ee. =3D > >> It > >>> would be possible to add another flag meaning to actually use the sta= te o=3D > >> 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 s= tand=3D > >> ard > >>> boolean options like {,no}atime into a bit, preserving the last optio= n > >>> specified. E.g. if the fstab lists noatime for a file system, and "m= ount=3D > >> -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 s= peci=3D > >> fied > >>> or the option was explicit. In theory, three states can be encoded u= sing > >>> nmount; options could include "atime", "noatime", or neither. But th= at's > >>> not what the current user level does, so changes are required. Given= tha=3D > >> t, > >>> it makes the most sense to have mount(8) and others to incorporate th= e > >>> default into their operation, and just give the kernel the answer. b= tw, > >>> 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 i= n > >> 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) co= nvers=3D > >> 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 configuratio= n. > > 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, me= dia). > 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. I think the only time (no pun intended;-) this will matter for NFS is if Fr= eeBSD were to adopt support of "relatime", which could be implemented over NFS fairly efficiently. rick > > Mike > >> > >> I'll admit I do not see what the default value of "(no)atime" is, so l= ong a=3D > >> s it > >> can be overridden on a per mount basis. A change to what the installer= sets=3D > >> , > >> seems fine to me. > >> > >> rick > >> > > > > [...] > > > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: Web: https://FreeBSD.org > > NTP: Web: https://nwtime.org > > > > e^(i*pi)+1=3D0