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.
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
