Date: Tue, 30 Jan 2024 13:48:11 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Rick Macklem <rick.macklem@gmail.com> Cc: Mike Karels <mike@karels.net>, Olivier Certner <olce@freebsd.org>, Warner Losh <imp@bsdimp.com>, freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Message-ID: <20240130214811.622C91B0@slippy.cwsent.com> In-Reply-To: <CAM5tNy5j3m-vqxTTFK82VzOecLwKCaRTFO2Xxofgj4WCXywvjg@mail.gmail.com> References: <ZZqmmM-6f606bLJx@int21h> <3896441.telDhacX5M@ravel> <CANCZdfppuaPgM40FpF6rCdTgwjVqOXivJpinNy=69KY7yncu7Q@mail.gmail.com> <1732771.R3xgXyqmLP@ravel> <BC3B5A6F-69BB-4F1E-8C51-56C2693A8435@karels.net> <CAM5tNy5j3m-vqxTTFK82VzOecLwKCaRTFO2Xxofgj4WCXywvjg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <CAM5tNy5j3m-vqxTTFK82VzOecLwKCaRTFO2Xxofgj4WCXywvjg@mail.gmail.c
om>
, Rick Macklem writes:
> On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels <mike@karels.net> 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 <Cy.Schubert@cschubert.com>
FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org
NTP: <cy@nwtime.org> Web: https://nwtime.org
e^(i*pi)+1=0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240130214811.622C91B0>