Re: noatime on ufs2

On 2024-01-09 00:47, Olivier Certner wrote:
>> Why not make noatime the default across the whole system? Outside of mbox 
>> why is recording access time actually useful?
> 
> Exactly.
> 
> I've never found any compelling reason in most uses to enable "atime", 
> except
> perhaps local mail but as addressed in other answers it is a relic of the 
> past
> mostly irrelevant today.  And its drawbacks are well known and can be 
> serious.
> 
> The auditing use is not what I consider "normal" in the sense I suspect it
> concerns a small minority of users (maybe even tiny).  Plus, serious 
> auditing
> requires keeping a log (generally immutable) of accesses, i.e., more than a 
> single
> time and, as pointed out in another answer, at least the ID of the user 
> performing
> the access.  Updating the access time field on files/directories doesn't 
> address
> both.
> 
> What "relatime" only gives you is a guarantee that you know that some file 
> has
> been accessed at some point after its last modification (or creation), and 
> that
> the access time is correct if precision is only a day.  It also generally 
> lowers
> I/O obviously, but not in some scenarios (file creation and subsequent 
> read).
> 
> So, to me, at this point, it still sounds more than a gimmick than something
> really useful.  If someone has a precise use case for it and motivation, 
> than of
> course please go ahead.
> 
> In the short term, I'd vote for turning "atime" off by default.
> 
> Thanks and regards.
Honestly! Why do we have to upend decades of usage and understanding? Just 
because
it's old doesn't mean it's wrong. Several weeks of replies confirm my initial 
belief --
atime as it is currently implemented, is as it should be.
Administrators and users have spent years to decades finessing their systems 
and
policies based on the way the OS works. In fact administrators and users 
*pick* their
OS based on the way it works. In the case of atime; decades of 
scripting/policy and
utilities have been created based upon the it's expected behavior on any 
given OS.
I haven't seen anything in this thread that wouldn't be better placed in 
tuning(7)
or tunefs(8).

* Silicon disks fail without warning
   tapes did as well. Unless you're working with punch cards please implement 
an
   effective backup strategy -- snapshot(8)
* writing to my disk takes a long time
   see tuning(7) or tunefs(8)
* atime doesn't work like "realtime" does on Linux
   use Linux instead or add the ability to also use realtime

Security and forensics are good reasons to keep atime unchanged. Any 
discussion
regarding changes to it's current behavior seems folly or bikeshedding.

Apologies for the "attitude".

--Chris