From nobody Mon Jan 08 20:41:02 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 4T85Z71z97z56k9G for ; Mon, 8 Jan 2024 20:41:19 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 4T85Z55d0Xz4Xxq for ; Mon, 8 Jan 2024 20:41:17 +0000 (UTC) (envelope-from delphij@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=lBUJLad6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of delphij@gmail.com designates 2a00:1450:4864:20::636 as permitted sender) smtp.mailfrom=delphij@gmail.com Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a2adc52f213so115520466b.0 for ; Mon, 08 Jan 2024 12:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704746474; x=1705351274; darn=freebsd.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=OC/rHOeYXHE2yfnMGAaBpFRMcpOUMApuC16av+6IXxQ=; b=lBUJLad6no9p8zHmR1LIqKizIEm2Sa1zSyiR1M4iOS20HryVmFXBnj3PKyWlUfEIOE FrA7KlZwru+5hWqqtP6wJziNv6sznTgzEO2o7nNPSaKE6gFV6Y70pMGAdVSHnlVkmwfR NOlO12+cuPbwwXnK9vI2neW4/Y/LnUWBP2XrRS8wKhoyPsAdVSdEDyw4cgvm+RcknQOE q7tbnjW9H3tXoCu5JUilymLBCzYKuWja6b8uvXcimETahZvJPiIKcSGhJ8q9m5l94sSW lkvLUZ6ULtRUJKDYXLlv2ThisFX0ALSF9LryJqPJsp3PPFjvB8mmM+qhBLaPkrMBhwwG 13IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704746474; x=1705351274; h=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=OC/rHOeYXHE2yfnMGAaBpFRMcpOUMApuC16av+6IXxQ=; b=ipxViH2CWwJZleEdd1QKVzEKpihwArqjfXhEUUZLxgYFoO1K9sPDVwgc5c81Ge2d5H pR1VIhGcF8jp1atcgAHOEYyF2DhfZ+Phh9l0opwFPfT8p9gFp2AHxqDXU1CO1L7ikfeY zPcuoNz4Nm15Fd5TzTOFMVCObqVl2xxxCl5wZc0aQYHjxdY5YfqRMPuk+rHm4qWmEUx7 jTh3E09N56mJ5DXD6/QHKw5eRpVON1OBH3GyPqc4eZBwkXQ4Hbzy9KBRksH8zme1t/Gv kRrAEEp7/sxGLlla8eOZt42wfBi1y2c021pmAxhVIDhcgk3G4XryVwOw4fq7iq64+3VJ R8Ew== X-Gm-Message-State: AOJu0YxypzFC1AaPgserbraEhgLYZXoPxsY/pfq0OQcxltK08+GnB1BJ N2LZ+Xtrm4w11vZuI9NXUv74Nf/wRwoZqcFSi6rE8LH1fSA= X-Google-Smtp-Source: AGHT+IGG8OorzKf+ib0NNl8GSwr1VNcHK0P+ztmGlLhxNOk3w/O2hh9qrll6vBlW7+RTythUmJIYAlYtwTuPs3g3uhQ= X-Received: by 2002:a17:906:1458:b0:a28:cf0a:c29e with SMTP id q24-20020a170906145800b00a28cf0ac29emr6440ejc.114.1704746473946; Mon, 08 Jan 2024 12:41:13 -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: Xin LI Date: Mon, 8 Jan 2024 12:41:02 -0800 Message-ID: Subject: Re: noatime on ufs2 To: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="00000000000003004c060e753845" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.90 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.899]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::636:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FREEFALL_USER(0.00)[delphij]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4T85Z55d0Xz4Xxq --00000000000003004c060e753845 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 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 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 changes 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 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 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. Cheers, --00000000000003004c060e753845 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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&#= 39;t matter if you don't normally receive emails locally (nowadays, it&= #39;s rare).

If you do receive emails locally, it depends on what ap= plication(s) that you are using.=C2=A0 Most applications nowadays check bot= h mtime and atime plus sizes of the mailbox file and do not rely on atime (= because they saved the previous mtime).=C2=A0 Without atime updates, some a= pplication may claim that you have new mail when the mailbox is not empty w= hen they first start.

That's said, if I were you and I'm usi= ng 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 r= eminds me that -- we probably should have implemented the Linux "relat= ive atime" (update atime iff (atime <=3D mtime || atime <=3D cti= me) || atime is older than a day) and "no diratime" (don't up= date directory atime) for UFS and make the "relatime" option the = default; I had an incomplete=C2=A0implementation about a decade ago somewhe= re but with the recent VFS changes it's probably easier to start over.= =C2=A0 IMHO, updating atime=C2=A0every time when a file is accessed is not = really providing useful data (like who accessed the file, etc.) for audit p= urposes and does come with performance (more write I/O) and reliability (we= ar 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 ha= s covered the most useful 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.

Cheers,
--00000000000003004c060e753845--