Date: Mon, 29 Jan 2024 11:27:05 +0100 From: Olivier Certner <olce@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: Current FreeBSD <freebsd-current@freebsd.org> Subject: Re: noatime on ufs2 Message-ID: <10218883.mV2X7mr0Zk@ravel> In-Reply-To: <74B030A5-6141-4FE2-AE8C-79548B82FAF0@yahoo.com> References: <F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677.ref@yahoo.com> <12921270.kl7XSLc1hW@ravel> <74B030A5-6141-4FE2-AE8C-79548B82FAF0@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2609540.JStIQ7tifP Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner <olce@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: Current FreeBSD <freebsd-current@freebsd.org> Subject: Re: noatime on ufs2 Date: Mon, 29 Jan 2024 11:27:05 +0100 Message-ID: <10218883.mV2X7mr0Zk@ravel> In-Reply-To: <74B030A5-6141-4FE2-AE8C-79548B82FAF0@yahoo.com> MIME-Version: 1.0 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 you= r 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 (c= hange of default, or have a sysctl to control the default). I've already l= isted three use cases in an answer to Warner that can't be covered by modif= ying '/etc/fstab', and two of them that can't by just specifying mount opti= ons to mount(8) on the command-line (the auto-mounters).=20 > 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 'noatim= e' aren't explicitly specified. This is a goal, not an unwanted side effec= t. > In case the potential confusion is involved I'm wondering if you might be confusing default options per mount (as a lin= e 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 a= pplies in any situation, barring explicit specifications by the administrat= or (or delegated software), which is why it belongs to the kernel (it has t= o 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 b= ike shedding where there is none, and/or use it as a tactic to try to disqu= alify 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 tim= ers. We haven't had much of that so far, except perhaps for a few mildly a= ggressive 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 s= leep(1) example is that I intended to drop an idea and gather reactions bef= ore having even produced code, because I wasn't sure on how it would be rec= eived and in particular what are the use cases that could be affected. Obt= aining this feedback is essential because this project is about people from= diverse backgrounds and needs. It also helps in clarifying a particular d= esign, which some answers fulfilled. I'm now at the point where the next s= tep 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 sa= ne defaults that match contemporary uses: It reduces the need for tweaks, w= hich serves both beginners but *also* seasoned administrators. This is in = isolation a very small step in this direction, but there have been others a= nd more will come. Collectively, they can build up to significant addition= al value for the project. Regards. =2D-=20 Olivier Certner --nextPart2609540.JStIQ7tifP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmW3fXkACgkQjKEwQJce JicpSg//YIxXX7O0Q6BD9vWa/FLj9hqy53iRzTS6t7i8m7ypCHVfbj7ACxP28jl6 O50HchsOpDJ1gbp4dO0bRRNMPkMWetFQU/rwWcD94QXbeDZ1oclj/BEwh0K31Zqu 5jqmQCy/fzkqJKTLBR/Xb8vTedLTUyz1uz4/2wfPLlgHjTwyinu03jmBSu+uLL2h aIrRGpFn1b43SZS45oNgifI+afqA756kocpA4URl5l4+qYZFzSTfReS0dGzqHnY4 S3KS7w0aXz0j1F5LoBI9Ur0swFGdxrAO+BJ59ONpFvyhtepGMf6ApoqtRnXL8ncI /znO1+3LoX3Kw4kf3rp8at58IBxrB1jog5iFeRL91Bhfbu+cpoQXZW6JxiHJRYw0 9pSpybB/tk02Rrd5xJ5m49fx8IUsFoHr07T7XPUXho+vE+tpG6zkUMNkA8CtGclN 4bumzwROY4u2vAvN+9Kb2RqKQdo4q9l3dKt6Dbqsh/1z1qSKqr3gFrO5KxS33sTR pph4UtCRxI+Xf2viByk84XhPc1N8Zv5LeSH9w6PDQJgVgD2Lgy4UemkhRNVNIpQn LFJ74NHZYYC0VOxjZGvMBT11MkGgtEy48mDAJGyPK8xgLQt0ggvtLdvh4JsUoMKW qRABr4z2q1iZC23S5XQq+yxPEbXNWP0IG0qGFEBaw3IPKaA8N20= =IKf/ -----END PGP SIGNATURE----- --nextPart2609540.JStIQ7tifP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10218883.mV2X7mr0Zk>