Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Jan 2024 12:41:02 -0800
From:      Xin LI <delphij@gmail.com>
To:        freebsd-current@freebsd.org
Subject:   Re: noatime on ufs2
Message-ID:  <CAGMYy3vsSD7HHtGxYXJn%2Busr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
In-Reply-To: <ZZqmmM-6f606bLJx@int21h>
References:  <ZZqmmM-6f606bLJx@int21h>

next in thread | previous in thread | raw e-mail | index | archive | help
--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 <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'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

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:monospace,monospace"><br></div></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jan 7, 2024 at 5:27=E2=80=
=AFAM void &lt;<a href=3D"mailto:void@f-m.fm" target=3D"_blank">void@f-m.fm=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
Hi,<br>
<br>
Does /var/mail still need atime?<br>
<br>
I&#39;ve installed a ufs2-based -current main-n267425-aa1223ac3afc on<br>
rpi4/8BG which installs into one / . If it&#39;s mounted with noatime,<br>
will it have consequences for /var/mail ?</blockquote><div><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:monospace,monospace">It doesn&#=
39;t matter if you don&#39;t normally receive emails locally (nowadays, it&=
#39;s rare).</div><div class=3D"gmail_default" style=3D"font-family:monospa=
ce,monospace"><br></div><div class=3D"gmail_default" style=3D"font-family:m=
onospace,monospace">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.</div><div class=3D"gmail_default" style=3D"font-famil=
y:monospace,monospace"><br></div><div class=3D"gmail_default" style=3D"font=
-family:monospace,monospace">That&#39;s said, if I were you and I&#39;m usi=
ng some flash based storage (with rpi it&#39;s highly likely) regardless if=
 I&#39;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.</div><div cla=
ss=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:monospace,monospace">This r=
eminds me that -- we probably should have implemented the Linux &quot;relat=
ive atime&quot; (update atime iff (atime &lt;=3D mtime || atime &lt;=3D cti=
me) || atime is older than a day) and &quot;no diratime&quot; (don&#39;t up=
date directory atime) for UFS and make the &quot;relatime&quot; option the =
default; I had an incomplete=C2=A0implementation about a decade ago somewhe=
re but with the recent VFS changes it&#39;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.</div><div class=3D"=
gmail_default" style=3D"font-family:monospace,monospace"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:monospace,monospace">Cheers,</div=
></div></div>

--00000000000003004c060e753845--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGMYy3vsSD7HHtGxYXJn%2Busr8GCOd-0Xe1crs-Nx=qw-bYJ6HA>