Re: noatime on ufs2

On Jan 15, 2024, at 01:27, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:

> On Sun, 14 Jan 2024 16:13:06 -0800
> Mark Millard <marklmi@yahoo.com> wrote:
> 
>> On Jan 14, 2024, at 14:27, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
>> 
>>> 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
>> 
>> I've not reported any objection to bsdinstall having explicit
>> choices required in its menus. Nor to changing how, say,
>> official snapshots are generated (so long as well notified
>> and documented). If my wording was unclear on that, I'm sorry.
>> 
>> My focus was on things like mount command notation and
>> /etc/fstab notation (that tracks mount defaults) or subroutine
>> interface equivalents of such things and changing their
>> behavior without requiring changing the notation already in
>> place in various files.
>> 
>> (I've tried to word the above without making new points,
>> avoiding contributing more to the bike shed material.)
>> 
>>> 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.
>>> 
>> 
>> 
>> ===
>> Mark Millard
>> marklmi at yahoo.com
> 
> So you mean changing behaviour of mount[_*] to default to noatime, in
> conjunction with configuration in /etc/fstab to default to noatime,
> right?
> So if changes are done as such, if anyone want atime active, add
> "-o atime" in mount[_*] command and/or "[,]atime" in /etc/fstab?

In my stated view, if bsdinstall is modified for UFS it should
generate /etc/fstab files with explicit "noatime" notation when
the user selects to not have atime.

If they select to have atime in use instead, two ways would work:
be explicit in /etc/fstab with an "atime" or leave it implicit
for what I've stated as my view. As far as I'm concerned, the
generated /etc/fstab could always be explicit, avoiding any
dependency on the default for lack of having explicit notation.

But, I'll note that the existing "man mount" only mentions
the "noatime" notation, not the possibility of an explicit
"atime". The same goes for "man fstab". No matter what, the
documentation could be explicit about both notations, noting
which ends up being the default for when the user's notation
is not explicit.

I've indicated that my preference for the lack of explicit
notation would be to continue to have it mean "atime" implicitly.
But tools like bsdinstall need not output files that depend on
that at all: the /etc/fstab files could always be generated with
explicit notation.

Hopefully, the above is clear and I can avoid having to yet
again describe my view. Again I've tried to word the above
without making new points, avoiding contributing more to the
bike shed material.

===
Mark Millard
marklmi at yahoo.com