From nobody Mon Jan 08 21:12: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 4T86Fv5Nkkz56pNw for ; Mon, 8 Jan 2024 21:12:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T86Fv0QG9z4gmD for ; Mon, 8 Jan 2024 21:12:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-a2a17f3217aso225307766b.2 for ; Mon, 08 Jan 2024 13:12:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704748338; x=1705353138; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6t46BCg077sBnDUQhm+f0+m/gnV2sEfKxqJhthHEOkM=; b=DMxhkTFKVyGZO7za5Thjk09YccgVr4NbrVNffxf/PQRUxDqUd3rptvViuvoQBrviYT wPWChK1Ft8cQlpxLqX4UQQtEIDqLa+1tx1WOdxSh5WKYLdXLkQRheBKh8ccdgw1KBtTh IEyLPYRB8WaDiEgr34w6CjWkFYY8SIeknEqki5WXYJF/OLOHG/Ow/HJSVtZeJsWXPBps 9XzJt4Ie/sFb9gsGVFgi/0NKhfyUFYgro6au4SIE96GpOWPm9RZV67uZijHgowKH9E/O KuHgIiC5IuCfPx1EW+6KD64pPhV2/YAPbCO8TSOLcLNYwRTMgHLF2k+QYD9pQQS/T0sR qSRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704748338; x=1705353138; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6t46BCg077sBnDUQhm+f0+m/gnV2sEfKxqJhthHEOkM=; b=FNIjSHrFnxnTXEtiqITQlAUuRAgK0//XzfArC9I6/fbE9HcvM9aNNtch2po9Fs0N51 zrQaToWQW4Anme/l8JsXemAFnNydhGbT1DsFbSM9rH1GJkn9LJ/jOTUUNAqZkO6pDH/r 9KGjuV68ivbmvjnIJRpmRpBjeticH6yvGTVs2Glf7kFPqpQIamnmqaa9/yGg/f3sxxuv 1z90zqmMYpU24CpE0tW67KS2ukPwedbFHjzRG2lrNphTCn05OWmBDjhACaZQ/6MSmQMc Ba7Rr0bcbaYUXr6Nng+0X9fHJ/UxK6Z0nxJe9t/vatUkUAJFgJfzZt1isaQPYMC1V1dk FD3A== X-Gm-Message-State: AOJu0Yz47oUDiQ31pdrZQserFufyxCTvyUm1RQzEYWY91bWnzx1U6b0q sglAsPmswtFLdUPXPm7uUrf5bK8+rvqCdqyLI1DzWV2LUPBibStoJznkYKzEALw= X-Google-Smtp-Source: AGHT+IE1+wVtdtT9aMIOhwAUcNBPUuNUJsGvBKBZbm//ZBCGBYN6i7Hkcv7FK2RvNuGF/juJMdJcazHA94ultegp7sI= X-Received: by 2002:a17:907:7f8e:b0:a23:46f2:d8e4 with SMTP id qk14-20020a1709077f8e00b00a2346f2d8e4mr25654ejc.51.1704748337619; Mon, 08 Jan 2024 13:12:17 -0800 (PST) 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 References: In-Reply-To: From: Warner Losh Date: Mon, 8 Jan 2024 14:12:06 -0700 Message-ID: Subject: Re: noatime on ufs2 To: Xin LI Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000001888a4060e75a716" X-Rspamd-Queue-Id: 4T86Fv0QG9z4gmD 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:15169, ipnet:2a00:1450::/32, country:US] --0000000000001888a4060e75a716 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 8, 2024 at 1:41=E2=80=AFPM Xin LI wrote: > > > On Sun, Jan 7, 2024 at 5:27=E2=80=AFAM void wrote: > >> Hi, >> >> Does /var/mail still need atime? >> >> 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 ? > > > It doesn't matter if you don't normally receive emails locally (nowadays, > it's rare). > > If you do receive emails locally, it depends on what application(s) that > you are using. Most applications nowadays check both mtime and atime plu= s > sizes of the mailbox file and do not rely on atime (because they saved th= e > previous mtime). Without atime updates, some application may claim that > you have new mail when the mailbox is not empty when they first start. > > That's said, if I were you and I'm using some flash based storage (with > 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 increase the > wear of your storage. > > 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 directory atim= e) > for UFS and make the "relatime" option the default; I had an > incomplete implementation about a decade ago somewhere but with the recen= t > VFS changes it's probably easier to start over. IMHO, updating atime eve= ry > time when a file is accessed is not really providing useful data (like wh= o > accessed the file, etc.) for audit purposes and does come with performanc= e > (more write I/O) and reliability (wear of SSD and other flash devices) > cost, therefore not generally useful in modern days. The Linux relative > atime is a pretty clever idea that has covered the most useful use case f= or > 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. > I like that compromise. It will miss a lot, but that 'miss' results in atime being good to only about a day, which for the vast majority of things is fine. Warner > Cheers, > --0000000000001888a4060e75a716 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 8, 2024 at 1:41=E2=80=AFP= M Xin LI <delphij@gmail.com>= wrote:

On Sun, Jan 7, 2024 at 5:27=E2=80=AFAM void <void@f-m.fm> wrote:
Hi,

Does /var/mail still need atime?

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 ?

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

If you do receive emails locally, it depends on what= application(s) that you are using.=C2=A0 Most applications nowadays check = both mtime and atime plus sizes of the mailbox file and do not rely on atim= e (because they saved the previous mtime).=C2=A0 Without atime updates, som= e application may claim that you have new mail when the mailbox is not empt= y when they first start.

That's said,= if I were you and I'm using some flash based storage (with 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 increase the wear = of your storage.

This reminds me that -- = we probably should have implemented the Linux "relative atime" (u= pdate atime iff (atime <=3D mtime || atime <=3D ctime) || atime is ol= der than a day) and "no diratime" (don't update directory ati= me) for UFS and make the "relatime" option the default; I had an = incomplete=C2=A0implementation about a decade ago somewhere but with the re= cent VFS changes it's probably easier to start over.=C2=A0 IMHO, updati= ng atime=C2=A0every time when a file is accessed is not really providing us= eful data (like who accessed the file, etc.) for audit purposes and does co= me with performance (more write I/O) and reliability (wear of SSD and other= flash devices) cost, therefore not generally useful in modern days.=C2=A0 = The Linux relative atime is a pretty clever idea that has covered the most = useful use case for atime (Did I accessed the file after it was last modifi= ed) and also provided a coarse-grained update (capped to daily, which is a = reasonable compromise) to the atime.
I like that compromise. It will miss a lot, but that 'miss&= #39; results in atime being good to only about a day, which for the vast ma= jority of things is fine.=C2=A0

Warner
= =C2=A0
Cheers,
--0000000000001888a4060e75a716--