Re: noatime on ufs2

Hi Rick,

> I do not have a strong opinion w.r.t. atime, but I do believe that
> changing the default would be a POLA violation.

While I value POLA very highly, at the same time I do not consider it a sacrosanct principle that must be followed in every possible circumstances.  There are many different ways and levels of being amazed, and varying counterparties to gain in exchange, so there cannot be any absolute interpretation of it.  Moreover, the stricter you are in general, the more you are pushing the project towards fossilization.  It's true that there are lots of mechanisms to allow both backwards compatibility and evolution in lots of different cases, but they come at a cost which is increased complexity, amount of code and configuration, which has to be taken into account as well.

Here, I do not think activating 'noatime' by default would be a significant violation of POLA.  On the contrary, I think that almost nobody will notice it, so there barely will be any amazement.  Why?  First case: The user/admin doesn't care, so is using the default.  Most of them will never ever use 'atime' for any purposes.  Some will try to use if a few times, discovering on occasion that they cannot because something messed up with them (if 'atime' is the default) or because they are not maintainted (if 'noatime' is the default).  Second case: The user/admin cares, and wants/needs to avoid the extra I/O, so decides to uses 'noatime'.  These people won't even notice a change, since they are using 'noatime' already.  Third case: The user/admin cares, and wants the access times to be updated.  If he's using an explicit 'atime', it's the same as the previous case.  If, as is likely, he's not explicit, he will notice the change as some of his scenarios will start to fail, with more or less bad consequences. I don't think this is really different than lots of changes the project has gone through.  The very important thing, but the only one, we would have to do is publicizing this part correctly ("if you're relying on access times, be sure to change your mount options, and possibly configure your auto-mounting applications and/or other mount helpers so that 'atime' is explicitly enabled.").

I address other POLA-related points raised by Mark Millard in a direct response to his mail.
 
> Please look at this email thread, where the opinion w.r.t. atime
> seemed quite different:
> freebsd-hackers@ Oct. 5, 2023
> Subject:  copy_file_range() doesn't update the atime of an empty file
> 
> I'd put a url here, but gmail always puts the subject line in here when
> I copy/paste the url?

No problem, I found it online.

I only re-subscribed to hackers@ a few months ago after discovering I had been seemingly unsubscribed for a while without knowing it.
 
> Basically I did not think that updating the infd's atime when copy_file_range()
> did not actually copy any data, but the collective disagreed, so I patched
> the NFSv4 client. (I do not know if markj@'s patch did get committed).
> They also collectively thought that Linux did a poor job w.r.t. atime.

I completely support the view that, if a copy realized through VOP_READ() updates the access time, so should a copy realized through copy_file_range().  That is arguably also an application of POLA, but in fact here is much more: A matter of correctness.

However I fail to see how that thread, as a whole, has any connection with the discussion we are having.  Could you please elaborate?

Thanks and regards.

-- 
Olivier Certner