Date: Sun, 14 Jan 2024 17:38:11 +0100 From: Olivier Certner <olce@freebsd.org> To: "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca> Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Message-ID: <6716110.NahNnZtspv@ravel> In-Reply-To: <a5e38bfbabd37084@orthanc.ca> References: <ZZqmmM-6f606bLJx@int21h> <6714298.qJWK8QVVMX@ravel> <a5e38bfbabd37084@orthanc.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1705252824.Ej03iQjLZH Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner <olce@freebsd.org> To: "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca> 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: <a5e38bfbabd37084@orthanc.ca> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6716110.NahNnZtspv>