In message <3f6cf45c-3d34-4da6-9b81-337eb70bb...@karels.net>, Mike Karels
write
s:
> 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> wro
> t=
> >> 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, bec
> a=
> >> 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 p
> r=
> >> 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 publ
> i=
> >> c API and mount(8) must always be used, the system call will still be ther
> e=
> >> 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) conver
> s=
> >> 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.
net doesn't work anyway. On my todo list.
> 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.
IMO the only reason to mount all filesystems noatime would be to reduce
wear on SSD devices. ZFS is easy. Local filesystems in fstab should be easy
today without source changes. A simple script or ansible playbook can
easily handle this. I've done this locally on my laptop, the only machine
here with an SSD.
Regarding network filesystems such as NFS and CIFS, that would be the
responsibility of that machine's admin for application to that machine's
local mounts. Network filesystems need not have such facility.
I suppose any mounts performed through devd would also need to be handled.
Considering all the different places we'd need to add support for defaults
I'm beginning to see the point of a global knob.
Regarding the utility of atime, some apps are sensitive to atime, which is
why Veritas NetBackup by default tries to maintain atime after backing up
(reading) files. (With a config option to disable this in lieu of
maintaining correct ctime.)
I think regardless of what we do implement a default mechanism we need to
be cognizant to not change the out-of-the-box default.
And to reiterate, I'd prefer fewer distinct changes with an isolated
change. Less to go wrong and less to miss during implementation. I.E.
cheaper on developer resources. Simple is better.
--
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
