Date: Wed, 10 Jan 2024 10:42:07 +0100 From: Olivier Certner <olce@freebsd.org> To: Steffen Nurpmeso <steffen@sdaoden.eu> Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Message-ID: <2367131.USjQqFH40Q@ravel> In-Reply-To: <20240109174318.MCIB6yhn@steffen%sdaoden.eu> References: <ZZqmmM-6f606bLJx@int21h> <5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastmail.com> <20240109174318.MCIB6yhn@steffen%sdaoden.eu>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Hi, > 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. 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 the "atime" mechanism addresses these needs poorly. With that in mind, developing "relatime" to try to alleviate the shortcomings 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", 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). 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") 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 > > 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’t break mutt(1) or other applications that need to > know if a file has been read since the last time it was modified.) > > 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. Which need(s) of yours are you trying to address exactly by using "relatime"? Thanks and regards. -- Olivier Certner [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWeZm8ACgkQjKEwQJce JifVYQ//X8bK0vxCXlaDS8NaF6oBkhMUmOeuQtGiw0ZOBQUTyE016Q5J5eoQwEbr rMwRrcFW4T6WJdT5AjBLzpP1GoNRmYTh9DstpHkSbqEAkOFhkZYtIpR3Ju84J6d4 CHhgYunI6J4RlJcfi/f+kzvHFNmtmm2OH5v4kuOC4bz99M/Go32y3g6fXYX0xmWf 3H/Cu4KYpBB7VSaWQmiXHCTSkX2bsvZfmgbaj72vGpLMpny9OiMlUyqZt1Y3OClv jNkG/jaFHYYfKnHw4rcu3/rXMikq7lWqJsYhgGUgQg3nzYD/XFNjotW3Ja1btSK7 UWE7YIQW0CKauwobtd+FXkPxD3AIszhyVJmR7RAPdcoyJAz+dF2dq77OyBAT1bxC ceFrQpf47ZLe4eq1z7wAPyo0iEu6KCtGo5YdyURC7/4y3kcoaR9v4cwAhaiK9mRA T4aUUNpxMwfCI4C6PxS30yxy9nmy5fy7L7Yp1K1arj0mGacfO6AkpVEW1bBmWTuU uj6sHSxjTp/rfJPrA2UtxsqTWMN281WghBIcQsHknpAzLrjtv1o+/h4g1np2ehFs 1SjyIR+aOfDWdekeyveROlNLHclo2DbbQgncBZ0fgAFmCfLh6oqNZfWtnk6i1kTz mbg3HE/wpmFL/OjcGFsumOa56wPbUMf690yiCh5ME5wuHR05grw= =tguU -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2367131.USjQqFH40Q>