From nobody Sun Jan 14 16:38:52 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 4TCgvf4JXJz56byt for ; Sun, 14 Jan 2024 16:38:54 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4TCgvf36YBz4Kwb; Sun, 14 Jan 2024 16:38:54 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705250334; 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=9l7d1WvECBQi9EgWpQ1D/hiA9a2++22ykX26IVpksgY=; b=tP0TZHO3tuChjnQHKSytE2j2QrAOL4Dp8n6wdj8zwuntm29dNJaKLKo06gsThtAyg67zKT DmgGY30fHCghqgajwZOBtmpEh3GL81QowSodu+1wn6ODS3qJHyoe8bi8ktmQoJfR8NJg6a 0clld95Enr1xyS0y+jKmKP+hf9aNP98fJLpi63tDbMu3lu1P0zlRyvJgCRpWLjUbYOqdX8 BNVQVc+UaVzVjxzo+MmYcJd2GD+I1uhGQFMalhfHoWLZftC4PAwHIkkpcxMT3k/amW1NrO n+LiWpNNwopzPTLoG+/G7+NZayRfr2vcYx5LStQ0KRXcTpUqhtfNOK96VDwU2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705250334; 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=9l7d1WvECBQi9EgWpQ1D/hiA9a2++22ykX26IVpksgY=; b=bxs325wmHKzQXIbL4uWv/M+O+5fNoN8g8MGYTk8vKFauD4yHJ2HlJz75nKYGQ3VIzzX8fN HIcIXRJqrAgIETYBWViV6ae8Wt/qC5LA7hhXkzdI9xCZ6ZOnp4odIpoeMp8zOqJc0Yj0E4 YtVhC3cIgrbLiPFYMrn7gPPn1ow8Q78xr8BB/3GtRguJczxCreiWxKEsyehSw7kAwoyEL9 rLp+SjLwcHxcYsq+UT1jBGWF3uAYkWAvaDQ/ouMvoaRz7hj3B7IhPP1xxugvekgrVYeFzO 4ffmQEw/ooI+LWSfudXWwIOQtmhzG7vEYV5jk6M/sRX6Fq0w+BoXr5kUjdto4Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705250334; a=rsa-sha256; cv=none; b=aanO0c4x2DdEmKs/ukEgXcksz7rD+7LkBGz/APoq4tmjmE01jpsnL0AU69QX2go4Cb690b 5vM47rhJpOmxPT99jDPOTXntijsZl0jHzMe6U7JyvxUACylE62WQ+lZIMDmhGrDA9LCsqq hWhNmChtr6QeMxhse2Kxxj86dBYFXP3f1hm3ecFdiSz8INGaqGzhskB8X0+2zvLhbn4z/Z 5mCQxYbEZK3Et5y5Lno99ZWQsTNNQqv1w3ss8Ft0+sva2qc+bNvvr/l8CMtgDCxuS636Xq yg3+kQddP0WgeiPwmcWoiJp5EPVmkF//UIY3dNtROGDmrixSBp70vZ+vVPej5Q== 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 4TCgvd6NK5z15Dr; Sun, 14 Jan 2024 16:38:53 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Rick Macklem Cc: "Lyndon Nerenberg (VE7TFX/VE6BBM)" , freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Sun, 14 Jan 2024 17:38:52 +0100 Message-ID: <4014880.cjyAsbXg9l@ravel> In-Reply-To: References: 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="nextPart12634010.pzjrNcfGrq"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart12634010.pzjrNcfGrq Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: Rick Macklem Subject: Re: noatime on ufs2 Date: Sun, 14 Jan 2024 17:38:52 +0100 Message-ID: <4014880.cjyAsbXg9l@ravel> MIME-Version: 1.0 Hi Rick, > I do not have a strong opinion w.r.t. atime, but I do believe that > changing the default would be a POLA violation. While I value POLA very highly, at the same time I do not consider it a sac= rosanct principle that must be followed in every possible circumstances. T= here are many different ways and levels of being amazed, and varying counte= rparties to gain in exchange, so there cannot be any absolute interpretatio= n of it. Moreover, the stricter you are in general, the more you are pushi= ng the project towards fossilization. It's true that there are lots of mec= hanisms to allow both backwards compatibility and evolution in lots of diff= erent cases, but they come at a cost which is increased complexity, amount = of code and configuration, which has to be taken into account as well. Here, I do not think activating 'noatime' by default would be a significant= violation of POLA. On the contrary, I think that almost nobody will notic= e it, so there barely will be any amazement. Why? First case: The user/ad= min doesn't care, so is using the default. Most of them will never ever us= e 'atime' for any purposes. Some will try to use if a few times, discoveri= ng on occasion that they cannot because something messed up with them (if '= atime' is the default) or because they are not maintainted (if 'noatime' is= the default). Second case: The user/admin cares, and wants/needs to avoid= the extra I/O, so decides to uses 'noatime'. These people won't even noti= ce a change, since they are using 'noatime' already. Third case: The user/= admin cares, and wants the access times to be updated. If he's using an ex= plicit 'atime', it's the same as the previous case. If, as is likely, he's= not explicit, he will notice the change as some of his scenarios will star= t to fail, with more or less bad consequences. I don't think this is really= different than lots of changes the project has gone through. The very imp= ortant thing, but the only one, we would have to do is publicizing this par= t correctly ("if you're relying on access times, be sure to change your mou= nt options, and possibly configure your auto-mounting applications and/or o= ther mount helpers so that 'atime' is explicitly enabled."). I address other POLA-related points raised by Mark Millard in a direct resp= onse to his mail. =20 > Please look at this email thread, where the opinion w.r.t. atime > seemed quite different: > freebsd-hackers@ Oct. 5, 2023 > Subject: copy_file_range() doesn't update the atime of an empty file >=20 > I'd put a url here, but gmail always puts the subject line in here when > I copy/paste the url? No problem, I found it online. I only re-subscribed to hackers@ a few months ago after discovering I had b= een seemingly unsubscribed for a while without knowing it. =20 > Basically I did not think that updating the infd's atime when copy_file_r= ange() > did not actually copy any data, but the collective disagreed, so I patched > the NFSv4 client. (I do not know if markj@'s patch did get committed). > They also collectively thought that Linux did a poor job w.r.t. atime. I completely support the view that, if a copy realized through VOP_READ() u= pdates the access time, so should a copy realized through copy_file_range()= =2E That is arguably also an application of POLA, but in fact here is much= more: A matter of correctness. However I fail to see how that thread, as a whole, has any connection with = the discussion we are having. Could you please elaborate? Thanks and regards. =2D-=20 Olivier Certner --nextPart12634010.pzjrNcfGrq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWkDhwACgkQjKEwQJce JiepJg//Wrlg/nwrqKY24TDuJcaTSX6UehSDPctTEXuJgHoiwIvjrWJpuj7LStsR N50GNJvnbVvrU5izGqa0xbeTlZTMqCHQVOHbuuH6xE9SiugyAfDKOta3siA3/7PF KGXoX/eIxxtDraRvsvTQ4yDOnZcTZbhAsAKo409t/K98FMY/Qun2Z3IKmFrDXeSb OTOC27YfBsimGcqFLfaDp4uhE65yr0Hrh08V55cSUgtoBBfquiP4gvpCN9AN+Psr zgo2ok6E0VNbp4slS8jB2l70oe/VYoDF5qDEV8rxaqwoyHQgmHjgXeEEICkjXbY/ JVJOj6vQk7m+gEZPX8nbBUXL1JRko458u2rzYWEdZ9tzZHv6DZTrd8VYbi3wa6+R gTYqqUaRWXBmuAI8YTqL+yOaIazzBv7hDATW7prVpk7EXrAB6R1DorMC+HDpEhSF n+EdPCikgUBT2KpAD4HypSkDk+YItVMrdt6j3yBBpfhWhtP4RRPF3YqMZwYvJi2O N/IrVT+gJNA1sPpvNBwNOR4epi5il3VyqS0BoAcVRjS48f/VA7LCTHGQPEch++z9 vfSmwOSQmJn7nIsz60cWj5vPDL4rAIYRe3jZI+Hb1z3AH8QWHF+NlDQAieuFsFvB RuCJt156r8RCCNFzXpr5KD5t4gm1um2duXE7/3fdFzo3dWuMHeo= =21UC -----END PGP SIGNATURE----- --nextPart12634010.pzjrNcfGrq--