On Jan 29, 2024, at 02:27, Olivier Certner <o...@freebsd.org> wrote: > Hi Mark,
Hello. Let me start out by indicating that some bike shed sessions are useful overall, even if not contributing to crucial matters. I do not see withdrawing from continued participation with new material as disqualifying of any of the rest of the overall effort in a bike shed session. Given what has already occurred in the session, I've nothing significant to add to the accumulated material and am trying to avoid adding less significant material that wastes effort/time. >> I'm confused: I go to the trouble to produce the same end result >> as your suggested change of defaults would produce, ending up >> with no recording of access times. > > That's nice of you, but unfortunately that's missing the point. First, you > claimed to "seriously care" about access time, so I simply asked about your > use cases, which you have not talked about. Second, your suggestions do not > (in fact, cannot) produce the same end result as what I'm suggesting (change > of default, or have a sysctl to control the default). I've already listed > three use cases in an answer to Warner that can't be covered by modifying > '/etc/fstab', and two of them that can't by just specifying mount options to > mount(8) on the command-line (the auto-mounters). I tried pointing out that my limited usage context is too narrow to make a reasonable generalization from for the overall problem. Auto-mounting is a good example that I'll point out relative to my usage context: What auto-mounting? But auto- mounting should be considered. I had to try to span beyond my usage context to form the options that I expressed. To only consider my usage would have been inappropriate. I can not use my usage context to justify coverage of that additional attempted span. Much of the overall usage is in that "additional attempted span". I will adjust and deal with whatever happens overall. That is something I know I can do for my usage context. >> . . . > . . . > > Is 'noatime' not being the default the biggest problem we currently have in > FreeBSD? I agree it isn't. However, it doesn't mean there is no value in > it. On the contrary, I think it is very important that the project has sane > defaults that match contemporary uses: It reduces the need for tweaks, which > serves both beginners but *also* seasoned administrators. This is in > isolation a very small step in this direction, but there have been others and > more will come. Collectively, they can build up to significant additional > value for the project. === Mark Millard marklmi at yahoo.com
