On Tue, Jan 30, 2024 at 2:57 PM Mike Karels <m...@karels.net> wrote:
>
> On 30 Jan 2024, at 15:48, Cy Schubert wrote:
>
> > In message <CAM5tNy5j3m-vqxTTFK82VzOecLwKCaRTFO2Xxofgj4WCXywvjg@mail.gmail.c
> > om>
> > , Rick Macklem writes:
> >> On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels <m...@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.
>
> 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.
I think the only time (no pun intended;-) this will matter for NFS is if FreeBSD
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 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.schub...@cschubert.com>
> > FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org
> > NTP: <c...@nwtime.org> Web: https://nwtime.org
> >
> > e^(i*pi)+1=0
