From nobody Mon Jan 15 10:31:17 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 4TD7jJ11XZz56Zp8 for ; Mon, 15 Jan 2024 10:31:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TD7jH2WcCz461s for ; Mon, 15 Jan 2024 10:31:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705314689; bh=Ehs+BLOHf3dX4Cxlgi+stbAYEbjgl2Ds/lUSuQgCXfg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Vta6pDZmIBtPO2hCoaGQCVaN+MuLQh+AlrhXJCfMXVTsNuuN6hzsZlY+F0BMMn4m0Ip3qeOY08r5klY/F2zphGhvTLpuZyIEb31Aw9QzyQHwMLRNax2ZweoVz7k4sUEHjqjRKPp+JmfMf+p3Z3/7JB/Ryh+j9dhsrHuVpHSPsCXoPedSQxkp0R+NqpvJB8VrjPltLqJuCpzYBIgYgdE/THPDUvivkJ8xiVUZy0lPhNGmsAKIFg2A/rNCs21o8y0Y2U4QMwlnGP1nlF9/5mdDj0M5u+swLwfwoHHZDMDSDWAx8ByeMlxcjW+GmlXr3Yy/aFLtWz+FJ3toby6AW+NetQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705314689; bh=Mh9g/QmUqIMYfRtI4HVMEO8CIVWIZGlMXaT8bq/4Wln=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IBoS+bGcj2ivX7ipHZcnJjSjkxbhcuRTxo8CDvw2yVGCjaRimMmBXwit2R7DE5fHL5XfpeE3wgwBgiKnXzZr9RJcYzIEumooowJlDvH7SnTEPHw6DNv3TRxOrkhm93ngOHdxvqQhYNQvLX8NL8oxGxRV518yStM/jQ9QFNp+uUSdKy3YgCauADtOV5nNuM1Hm+VX5eRkdo/Bi3+zSFUO8CGBA9ZaLEiBSRIc+928ddc5Ue4SsH3sJf0sHB4pAIjZU/VgvSXF6PuulRU8PGoRSsMyeqMSgqw/+/iE41di1/sYC7DV0ZtTTP6bCZlQgWHEEUNd3TNnSk1VPhHHVf6WTA== X-YMail-OSG: xMuy51sVM1keEp7_x.1nqoDzQtVgdFvYheQ2DSIDanmZ2UAAcXxJL0Yb4S6JEya lqkaAdVz67ItAvc.NgrH8nm._YotGryrrS7KJ9PikIrLy150SBYNc.lmHtPKSLoJP595A_2toDey wGMwUvAtAOc2aVGQ2eXWAdSdKCGIRm.UYJuOXVly4vIpcHeJQqftTPNBoa1AU7pZxz1AcA0M0Ove 7rNQA1WOhAsn_.3OxOO84MgOe1FnxOijyeGzSfIeKIIFb3PxhFgBSgSkMsTet.GR1eZeE9jQGo21 Pc.wsyGj9PQ0S76hqYKyii5y7KPQ7Db1gNm8j9eVi0Up_TqE19WXuq0qysupN2hJ6UFiEvTdo1Fo UskUw2gCNw47czgKxbaZUM3CIq3.WIeVC1UN4rX0E0cPo_0v5fW3x3XDipUQLliQITnQkokas1Fv Se8O30Nhjpd19B2OhMNERDOqJW0pP4MK0fS.P7xEFLXAvxLDARqKnZ1F8HszcuopS7HxMlXK3cGF Wc3Tl4xPHiLaCAkS2rdBhiwzSnuHEsb0n83tO2FdFMDsXy1JygPSe7qd9f3uVUotFkZEBAOzTrNG 40_BYSbrDK7jx9HTQRj1FKBz0FdMhV.rrdEwYizGsZumJeXsjWyCzXQF.Ws1umJJfST9xLs1Jn_H m5CPVNavF5U27byQ_MM0rt7xVv3Xai2xA5C4v7zgduHy.QqvgTBK8OzCNzsMcrmK9o4L_5TUtlhH y6S6YnDTQJTzweJGpsZodOPbU8KQrRpjEFL8J9r2vI8GKqpVrlqOruUM2N0dPlE8e_mqN6Worox1 fEkKIk_UhgJH_7NrBu1g64hYXWH.PG_YONpxjxH_wXqCG3H_euXJitJ4v0Q_RQ3UGSB7J5VfPmtO K9TvMD017yv5FhD.h3BGnd4TavILYO.3X2xriIWkIfwCMoueiNBy3WnysnDpoSxJR_Q1x3NvJVzV mjBLJigzB26PYnrD.4hP9kToOteyNfkxcPQ52GRS67Req0.u1838wA2SPtNFO0Q4IpMfgUfg6_dD ERunG6uQP0icQMSnbpcHqinCAYtNdNY._.9..V6biu3daVTte7fYRpsC36tSXRhySTZK06qFVoUK zpF5zIAe_OzLGjxK09AtC6.FezBr2iSJ3uHoaj3kVnysQPAIfWkNMkS3JW2_gJWg74sLZDotmB_K zY2YHxWQNxLsMlWqttPLDR_iO98DmsBccoXOfepUfCHUQeetxaaW3Jrw6j0ffIR7.f4gkngp_aIr XXgQNCHuDXcmTKBUCOhWo7ELE9oypnZ6Kgy1rCeZMwlszuvks4c8nQ7ONmx5L_gjNltccjIAwF5k .dQGMroRGhD0GJPrbad9y4cIvhKjJvdQOGwFQoMUFKLY4u.l_L1UqnLrrn4n8xOeoPJYWuVAlIi9 GxuEMlO2ym9Re1Kaz7bED5KqnlKzZ2RsJ2pkUQWuxzAWpAAkm37GKMfU8mHocbJ1bULCGY.bimPQ tlOIZ0Cy0hJbrsz0qOlYVUDYeeGUKA7wqbssp5Uqr1iUQWZzQLXKsEQaza5dj7jkc4SgXVNs5OJ1 1OxfHjksyD8l7GJatSFCo7VvhiO6G2akywV0O7ev54_P6wkrS3SWytKUANNZkhw39SHRyajqxOGN vSJkv2SwYiStMFBScy44gBMMAEMxgd0dp3XTmPk6ihVDvMv1z7q_sJsPCAoZru2sx0ldmNnzYcZE 5AmVO_yDzCs3Lvq5PIDga83snbxDza.CfutfFdI3G2HARc1QBbk28PbJEvDtqOAgqPYEJmKw3wm7 NRZM2I69licFtw6wC1AtViSy9n7ntCcz6Z6T03m8P6f2mi8_cbGWa9MDjwR7l2rJ74I6.w5WYeoO 5.QRvxeopATuQpAyxkub1nKI0CAnnQ4Y7FXkQDNmPDJBlsXRFeXfjEPiabWtUYsBYX5Ax0RTZEAR hzO.UDHnS82TAYSQjVEBI.ItW8Bn2cIvhZHDBlMp6LtEzD1AWFo4.DOfRRuy6FnrF3WUcZK.yeVt ITGYp6nWGUEWVk3P8QJHZg27Xdyx0noBZE4k8sim_0uIqSjeI3tFmit2MErnxtPSTvygj0gU_ogf HnnpOJTmdEpHDVaARYL6P0o8t.HxjrzODA6qx5iHOvPZGuKlvlJXX9m285tNp4TWQFnYo51lZmP8 kHBGeSNhTSwRibm5j79oCjz0fRIB00BW0ljWTuZ3jF1M9a_fo9KQ4I9ll0OC8pesmQfcCGwpm5vc x8ETfH17NUU5wuPnAGY7qDwogTxs2NpMGClw.xfqNJjgPuW51PiIuHgprH6amdxk3x27ptmLbHj4 - X-Sonic-MF: X-Sonic-ID: 030ebbe5-a88c-47c7-b70f-82b18c63deaa Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Jan 2024 10:31:29 +0000 Received: by hermes--production-gq1-78d49cd6df-xzd4p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a9e19db6f12ba00c2a1a48eb84e1a7f8; Mon, 15 Jan 2024 10:31:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: noatime on ufs2 From: Mark Millard In-Reply-To: <20240115182713.5abeab262fc4750fb3c45b53@dec.sakura.ne.jp> Date: Mon, 15 Jan 2024 02:31:17 -0800 Cc: Olivier Certner , Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <3183964.fD0qBhBWp0@ravel> <6A477CBE-692E-49F9-B21E-2C0D29F09766@yahoo.com> <20240115072732.85c2213714a658d3b98ab830@dec.sakura.ne.jp> <259993C7-D14C-48CC-9593-25FCC1741115@yahoo.com> <20240115182713.5abeab262fc4750fb3c45b53@dec.sakura.ne.jp> To: Tomoaki AOKI X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TD7jH2WcCz461s X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 15, 2024, at 01:27, Tomoaki AOKI = wrote: > On Sun, 14 Jan 2024 16:13:06 -0800 > Mark Millard wrote: >=20 >> On Jan 14, 2024, at 14:27, Tomoaki AOKI = wrote: >>=20 >>> On Sun, 14 Jan 2024 10:53:34 -0800 >>> Mark Millard wrote: >>>=20 >>>> On Jan 14, 2024, at 08:39, Olivier Certner = wrote: >>>>=20 >>>>> Hi Mark, >>>>>=20 >>>>>> I never use atime, always noatime, for UFS. That said, I'd never = propose >>>>>> changing the long standing defaults for commands and calls. >>>>>=20 >>>>> With this mail, you're giving more detailed objections on the = social/political aspects of the proposed changed, or as we usually say = more simply, POLA. >>>>>=20 >>>>> All your points are already largely weakened by the fact that, to = wrap-up in a single sentence at the risk of being slightly caricatural = (but then see my other mails), nobody really seems to care seriously = about access times. >>>>=20 >>>> I seriously care about having a lack of access times. Yet, I've no >>>> objection to needing to be explicit about it in commands and >>>> subroutine interfaces, given the long standing interfaces = (defaults). >>>> It would be different if I could not achieve the lack of access >>>> times. That defaults do not block having the desired settings makes >>>> the change optional, not technically required. The defaults are, >>>> thus, primarily social/political aspects of interfaces, not >>>> technical requirements to make things work. >>>>=20 >>>> Given that, I explicitly claim that avoiding POLA at this late = stage >>>> is my preference for the priority of competing considerations. I >>>> make no claim of knowing the majority view of the tradeoffs. I = would >>>> claim that, if the majority is not by just some marginal amount, >>>> contradicting that majority view for this would not be appropriate. >>>> (Again: the social/political aspects.) >>>>=20 >>>> And, hopefully, this is my last contribution to this particular >>>> bike shed. >>>>=20 >>>> =3D=3D=3D >>>> Mark Millard >>>> marklmi at yahoo.com >>>=20 >>> I would prefer violating POLA here, with, for example, forcing = admins >>> to choose explicitly with installer menu >>=20 >> I've not reported any objection to bsdinstall having explicit >> choices required in its menus. Nor to changing how, say, >> official snapshots are generated (so long as well notified >> and documented). If my wording was unclear on that, I'm sorry. >>=20 >> My focus was on things like mount command notation and >> /etc/fstab notation (that tracks mount defaults) or subroutine >> interface equivalents of such things and changing their >> behavior without requiring changing the notation already in >> place in various files. >>=20 >> (I've tried to word the above without making new points, >> avoiding contributing more to the bike shed material.) >>=20 >>> Choose whether you need to retain last file access time or not: >>> 1: Don't keep (current default) >>> 2: Keep last one (default before 15.0) >>>=20 >>> by hand, or via installer configuration or additional scripts. >>> Of course, existing installations should not be affected. >>>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >=20 > So you mean changing behaviour of mount[_*] to default to noatime, in > conjunction with configuration in /etc/fstab to default to noatime, > right? > So if changes are done as such, if anyone want atime active, add > "-o atime" in mount[_*] command and/or "[,]atime" in /etc/fstab? In my stated view, if bsdinstall is modified for UFS it should generate /etc/fstab files with explicit "noatime" notation when the user selects to not have atime. If they select to have atime in use instead, two ways would work: be explicit in /etc/fstab with an "atime" or leave it implicit for what I've stated as my view. As far as I'm concerned, the generated /etc/fstab could always be explicit, avoiding any dependency on the default for lack of having explicit notation. But, I'll note that the existing "man mount" only mentions the "noatime" notation, not the possibility of an explicit "atime". The same goes for "man fstab". No matter what, the documentation could be explicit about both notations, noting which ends up being the default for when the user's notation is not explicit. I've indicated that my preference for the lack of explicit notation would be to continue to have it mean "atime" implicitly. But tools like bsdinstall need not output files that depend on that at all: the /etc/fstab files could always be generated with explicit notation. Hopefully, the above is clear and I can avoid having to yet again describe my view. Again I've tried to word the above without making new points, avoiding contributing more to the bike shed material. =3D=3D=3D Mark Millard marklmi at yahoo.com