Hi Mark, > 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). > My focus was on things like mount command notation and > /etc/fstab notation (that tracks mount defaults) or subroutine > interface equivalents of such things and changing their > behavior without requiring changing the notation already in > place in various files. > Nothing about that of itself > implies that I'd want the defaults for mount notation or /etc/fstab > notation or the like changed --or that I'd want them unchanged. > To narrow of a context for such a judgment about defaults. These two paragraphs seem to contradict themselves. If you've gone to the trouble mentioned above, wasn't it precisely to avoid changing the defaults? Because changing them implies that the exact same mount(8) command-line or line in '/etc/fstab' will have a different effect if 'atime' nor 'noatime' aren't explicitly specified. This is a goal, not an unwanted side effect. > In case the potential confusion is involved I'm wondering if you might be confusing default options per mount (as a line in '/etc/fstab') and system defaults applying to all mounts. By design, the former can't apply to mounts not handled by '/etc/fstab'. The latter applies in any situation, barring explicit specifications by the administrator (or delegated software), which is why it belongs to the kernel (it has to apply to the relevant system calls). > (I've tried to word the above without making new points, > avoiding contributing more to the bike shed material.) Bike shedding has become so popular in these circles that some people see bike shedding where there is none, and/or use it as a tactic to try to disqualify what others are saying. The initial bike shedding email was about a simple, obvious change to sleep(1) that prompted a flame war lasting weeks, with unfriendly fire from the project's people, sometimes from the old timers. We haven't had much of that so far, except perhaps for a few mildly aggressive or emotional emails, and the thread was active for only 10 days. It was then paused for 12 days since I didn't find time to read the latest mails and produce answers until today. What sets it apart also from the sleep(1) example is that I intended to drop an idea and gather reactions before having even produced code, because I wasn't sure on how it would be received and in particular what are the use cases that could be affected. Obtaining this feedback is essential because this project is about people from diverse backgrounds and needs. It also helps in clarifying a particular design, which some answers fulfilled. I'm now at the point where the next step is to put up some code for review for a sysctl knob. 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. Regards. -- Olivier Certner
signature.asc
Description: This is a digitally signed message part.
