Re: noatime on ufs2
- In reply to: Mike Karels : "Re: noatime on ufs2"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 31 Jan 2024 14:03:03 UTC
On Tue, Jan 30, 2024 at 2:57 PM Mike Karels <mike@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 <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. > > 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.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