From nobody Tue Jan 9 02:39:06 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 4T8FZW09N3z55lD1 for ; Tue, 9 Jan 2024 02:42:11 +0000 (UTC) (envelope-from robert@rrbrussell.com) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8FZV271vz4Xk4 for ; Tue, 9 Jan 2024 02:42:10 +0000 (UTC) (envelope-from robert@rrbrussell.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rrbrussell.com header.s=fm2 header.b=VMTh6LNT; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=aeZxZsec; dmarc=pass (policy=quarantine) header.from=rrbrussell.com; spf=pass (mx1.freebsd.org: domain of robert@rrbrussell.com designates 64.147.123.25 as permitted sender) smtp.mailfrom=robert@rrbrussell.com Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C791B3200A33 for ; Mon, 8 Jan 2024 21:42:08 -0500 (EST) Received: from imap52 ([10.202.2.102]) by compute1.internal (MEProxy); Mon, 08 Jan 2024 21:42:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rrbrussell.com; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1704768128; x=1704854528; bh=V4iumuCCJU T8r2tcRQki0yDYC/8B7SmTrSexSlgucGA=; b=VMTh6LNTGvlYGwBOVjxUFcYn2A vog7dyqW5m1rKxi1h4MqySWh3Aj1a0klli3wo6MHn6y71F/YdskDmg7rjfO3zHZ4 wy9rVboA1OsBGHa51AQuyU8GwZOqH8Cio1UFeuj6v4wRJYu/OmgccqhNd3UhgfOc INZDEVNXMQXYYGclAGi/njg0g3YoTw60VRSbneQoItN7Re7ClRsgHHYEI6Gk5nvb S0vCkeE5YK04bYpEWT4+Sv3+MJS15r2ptdnZcUuziFPvAzVsYv3FxHtW2XwvXSXe F1HEfldJFOa02EmEOYaTNAhRZf0IrMCoAY+EZyhkA0j0Qm95Kmz39viyP+tw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1704768128; x=1704854528; bh=V4iumuCCJUT8r2tcRQki0yDYC/8B 7SmTrSexSlgucGA=; b=aeZxZsecJudmrkoqkwFTPpXS8OyWTXcMKlPLv9Kb6+GW 9lCWReBh3tjmDZjhhFGiMrd6fBURQ2/qgRTiSeBKoP4N0m9MpAoAWEBMKBcm/ERm NRNs8E97U7vGCe/uzwGWHH94tpylHPADUt+Mmc8G0kOWj2OKUwbCtOHVS97ptYpK 5cGn2m4wEMUahdNkGiarACku5ZSJoTwcebgzKOUduoOTE3qsdRM2RZldSD+/+jYA wiY/OSpkZIhftWYnJvuNbtyLbLYiz60wmimBadcz/zsOcrcYhYdx62AMeAJTqqA9 EcplheNlObqWirqZBzz4SmhXFQO1xBuR/EDI750MjA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehkedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpehrohgsvghrthesrhhrsghruhhsshgvlhhlrdgtohhmnecu ggftrfgrthhtvghrnheptddvhedvkeejieefveffgedukedtleehffevgfekvdehkeetie dtgeelkeeftdefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomheprhhosggvrhhtsehrrhgsrhhushhsvghllhdrtghomh X-ME-Proxy: Feedback-ID: ie421460a:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id E786BC63EC9; Mon, 8 Jan 2024 21:42:07 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1364-ga51d5fd3b7-fm-20231219.001-ga51d5fd3 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 Message-Id: <2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com> In-Reply-To: References: Date: Mon, 08 Jan 2024 20:39:06 -0600 From: robert@rrbrussell.com To: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Content-Type: multipart/alternative; boundary=54b92331b9ec41dc9f02046dfeeac9b9 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.09 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[rrbrussell.com,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; R_DKIM_ALLOW(-0.20)[rrbrussell.com:s=fm2,messagingengine.com:s=fm2]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from]; XM_UA_NO_VERSION(0.01)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[robert]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NO_DN(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[rrbrussell.com:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4T8FZV271vz4Xk4 --54b92331b9ec41dc9f02046dfeeac9b9 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 8, 2024, at 14:41, Xin LI wrote: >=20 >=20 > On Sun, Jan 7, 2024 at 5:27=E2=80=AFAM void wrote: >> Hi, >>=20 >> Does /var/mail still need atime? >>=20 >> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on >> rpi4/8BG which installs into one / . If it's mounted with noatime, >> will it have consequences for /var/mail ? >=20 > It doesn't matter if you don't normally receive emails locally (nowada= ys, it's rare). >=20 > If you do receive emails locally, it depends on what application(s) th= at you are using. Most applications nowadays check both mtime and atime= plus sizes of the mailbox file and do not rely on atime (because they s= aved the previous mtime). Without atime updates, some application may c= laim that you have new mail when the mailbox is not empty when they firs= t start. >=20 > That's said, if I were you and I'm using some flash based storage (wit= h rpi it's highly likely) regardless if I'm using mail locally; most of = the time the data is not really useful for anything, and it does increas= e the wear of your storage. >=20 > This reminds me that -- we probably should have implemented the Linux = "relative atime" (update atime iff (atime <=3D mtime || atime <=3D ctime= ) || atime is older than a day) and "no diratime" (don't update director= y atime) for UFS and make the "relatime" option the default; I had an in= complete implementation about a decade ago somewhere but with the recent= VFS changes it's probably easier to start over. IMHO, updating atime e= very time when a file is accessed is not really providing useful data (l= ike who accessed the file, etc.) for audit purposes and does come with p= erformance (more write I/O) and reliability (wear of SSD and other flash= devices) cost, therefore not generally useful in modern days. The Linu= x relative atime is a pretty clever idea that has covered the most usefu= l use case for atime (Did I accessed the file after it was last modified= ) and also provided a coarse-grained update (capped to daily, which is a= reasonable compromise) to the atime. >=20 > Cheers, On the Linux side of things I think almost of the mail handling programs= have migrated to either using MailDir or MH style mailboxes, which don'= t need atime, for anything local. The MDA/MTA configuration examples hav= e all used MailDir for around a decade now. Why not make noatime the default across the whole system? Outside of mbo= x why is recording access time actually useful? --54b92331b9ec41dc9f02046dfeeac9b9 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 8, = 2024, at 14:41, Xin LI wrote:


On Sun, Jan 7, 2024 at 5:27=E2=80=AFAM void <void@f-m.fm> wrote:
<= blockquote class=3D"qt-gmail_quote" style=3D"margin-top:0px;margin-right= :0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-le= ft-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><= div>Hi,

Does /var/mail still need atime?<= br>

I've installed a ufs2-based -current main= -n267425-aa1223ac3afc on
rpi4/8BG which installs into one= / . If it's mounted with noatime,
will it have consequen= ces for /var/mail ?

It doesn't = matter if you don't normally receive emails locally (nowadays, it's rare= ).

If you do receive emails locally, it depen= ds on what application(s) that you are using.  Most applications no= wadays check both mtime and atime plus sizes of the mailbox file and do = not rely on atime (because they saved the previous mtime).  Without= atime updates, some application may claim that you have new mail when t= he mailbox is not empty when they first start.


This reminds me t= hat -- we probably should have implemented the Linux "relative atime" (u= pdate atime iff (atime <=3D mtime || atime <=3D ctime) || atime is= older than a day) and "no diratime" (don't update directory atime) for = UFS and make the "relatime" option the default; I had an incomplete = ;implementation about a decade ago somewhere but with the recent VFS cha= nges it's probably easier to start over.  IMHO, updating atime = ;every time when a file is accessed is not really providing useful data = (like who accessed the file, etc.) for audit purposes and does come with= performance (more write I/O) and reliability (wear of SSD and other fla= sh devices) cost, therefore not generally useful in modern days.  T= he Linux relative atime is a pretty clever idea that has covered the mos= t useful use case for atime (Did I accessed the file after it was last m= odified) and also provided a coarse-grained update (capped to daily, whi= ch is a reasonable compromise) to the atime.

= Cheers,

On the Linux side of things I think a= lmost of the mail handling programs have migrated to either using MailDi= r or MH style mailboxes, which don't need atime, for anything local. The= MDA/MTA configuration examples have all used MailDir for around a decad= e now.

Why not make noatime the defau= lt across the whole system? Outside of mbox why is recording access time= actually useful?

--54b92331b9ec41dc9f02046dfeeac9b9--