Re: noatime on ufs2

On Mon, 8 Jan 2024 14:12:06 -0700
Warner Losh <imp@bsdimp.com> wrote:

> On Mon, Jan 8, 2024 at 1:41 PM Xin LI <delphij@gmail.com> wrote:
> 
> >
> >
> > On Sun, Jan 7, 2024 at 5:27 AM 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 <= mtime || atime <= 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.
> >
> 
> 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,

Looks great if possible.
Maybe /usr/bin/mail would be almost all of the MUA which actually
require atime and local mailboxes (under /var/mail) would usually be
used for local cron-generated ones. Others would use POP or IMAP
running on different computer in most cases, I think.

Regards.

-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>