Date: Wed, 10 Jan 2024 20:12:15 +0100 From: Steffen Nurpmeso <steffen@sdaoden.eu> To: Olivier Certner <olce@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Message-ID: <20240110191215.fTrYqOW3@steffen%sdaoden.eu> In-Reply-To: <2367131.USjQqFH40Q@ravel> References: <ZZqmmM-6f606bLJx@int21h> <5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastmail.com> <20240109174318.MCIB6yhn@steffen%sdaoden.eu> <2367131.USjQqFH40Q@ravel>
next in thread | previous in thread | raw e-mail | index | archive | help
Hallo Olivier Certner wrote in <2367131.USjQqFH40Q@ravel>: |> I would not exactly call this a gimmick. | |I wish I hadn't used that term since it attracts too much attention \ |on itself, making people forget it was part of a sentence that was \ |quite balanced and seemingly altering their judgement. Sure. |I think you're confusing the need and the mechanism (or implementation). \ | In substance, we (Robert and I) were talking about turning "atime" \ |off *by default*. What I tried to convey is that the needs that justify \ |this mechanism are those of a minority in my view (and I'm certainly \ |not opposed to be educated if it's not true), and additionally that \ It is not true. |the "atime" mechanism addresses these needs poorly. I hate atime. In the past i always turned it off on most partitions, under FreeBSD. If i recall correctly reading FreeBSD documentation (which was my main UNIX learning factor; including the /usr/share stuff that i much admired) ignited that feeling of waste of prescious time (on a Cyrix 166+ with 49 MB RAM and a, uh, maybe 200 or ~250 MB hard disk -- i have forgotten!, i seem to recall about ~300 or 330 MB/sec memory and ~30 MB/sec cached disk performance (Linux), and i am pretty sure about the less than 5 MB/sec otherwise). I think i always used noatime by this time, on FreeBSD (whenever i read out the old IDE disks i hopefully will discover also that). I seem to recall "birth time" did not exist. Now it must be said that today i do not care that much. I do not even have a special partition for /var no more (on the laptop, at least). The memory and that incredible NVME disk are so unbelievable fast that i would not even have dreamed of it. Whereas i still do not truly look at access time myself consciously, i let it happen. (Unless it does not make sense; for example /x/music -- greetings to Kaiserslautern! -- is actually living on multiple disks, and (backup) sticks (well those: actually all), and it is only hm populated on one master (at the moment not NFS shared, but maybe later). That is then cloned everywhere. So. Hm. Ie, twenty and more years ago i surely would have agreed in that i turn(ed) off atime, but today, .. i for myself use relatime here. Also: as a general by-default policy: i do not think so. (But i am only a user.) |With that in mind, developing "relatime" to try to alleviate the shortco\ |mings of "atime" has a low ROI: It doesn't add the crucial functionality \ |most needs (like auditing) would require and doesn't even really address \ |the I/O shortcomings in some frequent scenarios. Deactivating "atime", \ Aha? Which? Today?? Well i mean writing must happen. |by contrast, doesn't require any development, suppresses all I/O overhead= , \ |and doesn't suppress any functionality for an overwhelming majority \ |of uses (at least, this is my current view; other inputs welcome). Not mines. |I did not say that the needs themselves are a gimmick, e.g., having \ |a notification of new mail (although, in this case, frankly, I'm on \ |the verge of arguing it). Simply, relying on "atime" (or "relatime") \ Actually it is often distress, as i work on multiple terminals, and the reported "new" mail has often already worked when the message appears. :) |for this is unnecessary, as you must have understood reading the various \ |previous answers in this thread. | |> On Linux mount(8) from https://github.com/karelzak/util-linux says |>=20 |> relatime |> Update inode access times relative to modify or change time. \ |> Access |> time is only updated if the previous access time was earlier than |> or equal to the current modify or change time. (Similar to \ |> noatime, |> but it doesn=E2=80=99t break mutt(1) or other applications that = need to |> know if a file has been read since the last time it was modified= .) |>=20 |> and this is what i use, except for some noatime mount points |> (/x/doc, /x/music, /x/pub, to be exact). | |It seems that the other answers (mostly those of Robert IIRC) have \ |shown that this manpage text isn't up-to-date with current practices. Ah ja? |Which need(s) of yours are you trying to address exactly by using "relat\ |ime"? I address that i do not turn off atime. Actually i do not, but get that automatically. But would otherwise. I only set noatime at times. Some utitilities even actively restore access time after they are doing their thing, in a standardized way. |Thanks and regards. I think i want to day that i would not like it if a global policy enforces noatime. Especially since the necessary changes are small, and could even be automatized easily. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240110191215.fTrYqOW3>