Skip site navigation (1)Skip section navigation (2)
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:  <12921270.kl7XSLc1hW@ravel> <74B030A5-6141-4FE2-AE8C-79548B82FAF0@yahoo.com>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
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
[-- Attachment #2 --]
-----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-----
help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10218883.mV2X7mr0Zk>