From nobody Sun Jan 14 16:38:11 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TCgv04BhHz56c8T for ; Sun, 14 Jan 2024 16:38:20 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCgv029Pyz4JWF; Sun, 14 Jan 2024 16:38:20 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705250300; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eDnKqXMS9gTwijFGu0Mxu+ZIJRgZ06VxXSNxygZWtWI=; b=TcG3izOdBwbKkP9l/soAWgatalTKEd558AL4ZIH3gtPYpJQfJaZL5ejJFEdWNYZFdZuDrE ueIJX5gct+nFN5CEP9jt62UOJ+Jq2HHjoU4jOTQTIpg9X6JHcj7TFRtiL9VK+LuIXiOo3S 2mA85CI0YE2xgvkSlVpl7mCgNkie9XsD3LpY7m0Cdb9HDJOHfGdUN4GAV+Ra/lByl+Bv1Z T4XEfIwHl0EaPVKehzGUwXjA41yJS2vTYwzaDKmLTCGoTX2ri7xq1Dy35Vw+1g6OnMwpdO r4Yt8tCl2LMHxCpwdbVGoq2HytMHSpGJqwtO99LqHSGe7i6VUm5TPd3rJZyA8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705250300; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eDnKqXMS9gTwijFGu0Mxu+ZIJRgZ06VxXSNxygZWtWI=; b=CyDCxQjR9NspFN+ug0WF9UgGY2vG4Ia6ZNIhtxh01WeVrA3elN+udt+62nJCcjp+Bxu3nL 3FodVZH+2Wt6SjGdnIiI5EICIgyYEx2OzFytrhmzvINviJK4SFa2b/88YZywo+xBdOB1WY JZRbwUUTHdmajePLpkN35J8fodASXqBpVPAcZ4cMwa6qqS70+v6XcxaiyFPYmPrDxqW4c6 ipiKDR35eplYzyVzLyOa7+cC5IM4tXU2PU5e3wrMjPh+kgMsySQaD+EL1UAwqKAFpGoqjy WgzVaDlQvVJq/S7djxLeVN8JQkdvniYbm0oxaNauPgRtJ5AJLK7HwUKuVDwdpA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705250300; a=rsa-sha256; cv=none; b=Hw0m53qJOHDXjHzXOSVEqNibsVCuMsOOrf/Db++TEpOqQpCiJ34X1MpyDPKOCnDuVsVcID mZ6ZNA4bKi3jypUIvIIb5UAf+e2PDaOmKPSoZ4KwOXR2ps5qr59s1/SHbHvx6T1g+zS+gv guoDt0mlpUHDMIXrtjO5r0TknSeXKuMdCGrHEaOcsaRZ7rYFr0mkQj7HIlLIKAmhzObWiQ fotZMO6JXEdSyuyKEsw0lQSxbl9b8fRxCrVCInF/hNx/1PHD+fQ2jkd4WwjBB0/gnnGKQw Hm7nn0fyHsKPoaqykNaGVJMBp+cZ4szoSQ+6bm4bmecodxMkgSsfPyLxZQvDBQ== Received: from ravel.localnet (lfbn-nic-1-525-172.w90-118.abo.wanadoo.fr [90.118.140.172]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TCgtz613cz156d; Sun, 14 Jan 2024 16:38:19 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: "Lyndon Nerenberg (VE7TFX/VE6BBM)" Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Sun, 14 Jan 2024 17:38:11 +0100 Message-ID: <6716110.NahNnZtspv@ravel> In-Reply-To: References: <6714298.qJWK8QVVMX@ravel> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1705252824.Ej03iQjLZH"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart1705252824.Ej03iQjLZH Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: "Lyndon Nerenberg (VE7TFX/VE6BBM)" Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Sun, 14 Jan 2024 17:38:11 +0100 Message-ID: <6716110.NahNnZtspv@ravel> In-Reply-To: MIME-Version: 1.0 Hi Lyndon, > > I've never found any compelling reason in most uses to enable "atime", > > except perhaps local mail (snip). > When UNIX ran on PDP-11s and disk pack sizes were measured in the > tens of megabytes, atime was very helpful in determining which files > were likely candidates for archiving to tape when the disk was > getting full. I appreciate this kind of historical information. According to Wikipedia, = most of the PDP-11's lifespan after my birth date overlaps only with my chi= ldhood and teenage years, and I had never the chance (or curse, I don't kno= w) to get around to one (actually, I only learned about its existence years= later, much after after its phasing out). This purpose, i.e., "determine which files to archive", was achieved by rel= ying on 'atime' I guess by selecting those whose access times were the olde= st (perhaps combined with other criteria). The mean employed here is exact= ly the same as for the use cases reported by Warner: Being able to know whi= ch executables / libraries / packages are effectively used. So this approach has exactly the same problems. As I explained in a respon= se to Warner, it is currently almost unpracticable on FreeBSD, because some= periodic processes mess up with the access times (for more details, please= read it). But more deeply, as sketched in that response, the problem is "g= eneral": Relying on access times is bound to be fragile, simply because the= y are updated implicitly, without the applications asking for it at all and= for most neither being aware. The use cases presented for 'atime' so far = all assume that the access times will be updated only on some action that i= s relevant to their scenarios. But you can't prevent other actions not in = your scenario from updating these access times, and it can be very hard in = practice to predict which can occur on a given install (depending, e.g., on= how many software packages you've installed, their provenance, etc.). In = some answer, Jamie Landeg-Jones suggested to have a per-process flag to con= trol the implicit access times update, which is a workaround that is probab= ly enough in some use cases, but not for all (see my response there). At t= he same time, I'd like people to realize that it is still no more than a wo= rkaround, or a "clever" way to solve one's problem in particular circumstan= ces, but is not a generally reliable solution. What I'm evoking here concerns more the "usefulness of 'atime'" discussion = than the "default should be 'noatime'", but has non-negligible bearing on t= he latter. > And in the Usenet days it was common to mount > /var/spool/news noatime, which eliminated a *lot* of meta-info > write traffic. A logical, completely predictable move. =20 > These days, other than /var/mail, I can't think of a compelling use > for it. I've been running my Plan 9 systems with atime disabled > ever since fossil arrived (decades) without any impact. I agree. That's exactly the reason why I wanted to seize the occasion of r= obert@rrbrussell.com's question to present my take, because I had been wond= ering about that a few times in the last 5 to 10 years and also never encou= ntered a compelling reason for why it should be the default. And I insist: The initial discussion, and my main focus, is about 'noatime'= becoming the default. The discussions about the usefulness of 'relatime' = and 'atime' are very interesting, and I'm even participating to those, but = to me are secondary in the end. The usefulness of 'atime' is of course in = part connected to the default to use, but they are still very different que= stions. For example, concerning the former, the frequency of needs (how ma= ny uses?) is not very important, whereas it matters a lot when it comes to = which default to choose. > I don't see any issue with making noatime the default. For those > that must have it, /var/mail can be carved out as a distinct > filesystem and mounted appropriately. The summary of the technical side of this discussion so far is that there m= ost likely won't be any issue at all for the vast majority of users if 'noa= time' becomes the default. We'll see if more reports for other scenarios a= re to come (or if we can find or guess some ourselves; irrespective of whet= her they validate or not the current evaluation). And, as reported by others, even /var/mail should not need it in most uses = given that all prominent MUAs have long departed from using the access time= comparison alone. (I won't pronounce myself on this since I'm not persona= lly using them, but I'm not seeing any reason not to trust the reports. If= some people have contradictory facts, I hope that they will present them.) Thanks and regards. =2D-=20 Olivier Certner --nextPart1705252824.Ej03iQjLZH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWkDfMACgkQjKEwQJce JicLGQ//QKEfDNDf5GUHTNm2bVEZ8kiHsDGsp4wu0iQETXM841D83ITJUOyvr3P+ K+379spvh9lbaWi2CS6FlpyWdvT3Zv/unyi5/EkJcqH/kG1XSmbJp16AxwBEQkD0 EVH3iuKTIPviTh85UUbwnzn0v35Zh2HrEzkax80ayuMYLJqvJsfzDKo50Joi54A7 iLX4CCp2Kdm7X1IwgU/R2c49EKVS81Mm/NEyWU9jTdD+CC/5yM0sJZqeFEujiAWs yTlLY+3S/UoHfexMUqIn34RTqpPtTL4cVkemK155Cpbcp1ueJ1X6L+MW9bybhWbX VSYGJOCHIa6Vncg4rACtiEt2CT18y8Vqcempl7nL/07F/9XGLUJctFqwBCiZeQbD 4WbublsZWTxwZJyhiaO8rAUojVGURdVDCwpWoVU/9nebQ8XZ2xSVl8Fk0b/AyNgd I9ODdxHV48L3b0u3VmS1FTqQJED1sYoXLxQpqbpk0Glb79EDiPU5F/qP5MjHzMp0 EmvHy+4mzZJncKR4OE0iwITwK9BxOeElNN/5EMF0SGuO1/DFpcgUiaNSZ6HHZgv8 /TNXGy31WHU3jQgS+PDG9XZxKSEAjShOULuhgxKCgvoTwl9NBM4HcKphAS/g5DBx f+JGcMmu6HftVzWVM45hrs9ZUpg8wBFW/U9Nny1BQybp/jALXVc= =hx/x -----END PGP SIGNATURE----- --nextPart1705252824.Ej03iQjLZH--