Re: noatime on ufs2

On Sun, 14 Jan 2024 10:53:34 -0800
Mark Millard <marklmi@yahoo.com> wrote:

> On Jan 14, 2024, at 08:39, Olivier Certner <olce@freebsd.org> wrote:
> 
> > Hi Mark,
> > 
> >> I never use atime, always noatime, for UFS. That said, I'd never propose
> >> changing the long standing defaults for commands and calls.
> > 
> > With this mail, you're giving more detailed objections on the social/political aspects of the proposed changed, or as we usually say more simply, POLA.
> > 
> > All your points are already largely weakened by the fact that, to wrap-up in a single sentence at the risk of being slightly caricatural (but then see my other mails), nobody really seems to care seriously about access times.
> 
> I seriously care about having a lack of access times. Yet, I've no
> objection to needing to be explicit about it in commands and
> subroutine interfaces, given the long standing interfaces (defaults).
> It would be different if I could not achieve the lack of access
> times. That defaults do not block having the desired settings makes
> the change optional, not technically required. The defaults are,
> thus, primarily social/political aspects of interfaces, not
> technical requirements to make things work.
> 
> Given that, I explicitly claim that avoiding POLA at this late stage
> is my preference for the priority of competing considerations. I
> make no claim of knowing the majority view of the tradeoffs. I would
> claim that, if the majority is not by just some marginal amount,
> contradicting that majority view for this would not be appropriate.
> (Again: the social/political aspects.)
> 
> And, hopefully, this is my last contribution to this particular
> bike shed.
> 
> ===
> Mark Millard
> marklmi at yahoo.com

I would prefer violating POLA here, with, for example, forcing admins
to choose explicitly with installer menu

  Choose whether you need to retain last file access time or not:
    1: Don't keep    (current default)
    2: Keep last one (default before 15.0)

by hand, or via installer configuration or additional scripts.
Of course, existing installations should not be affected.

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