On Wed, Jan 10, 2024 at 3:01 AM Olivier Certner <o...@freebsd.org> wrote:
> Hi Warner, > > > It has also been used for almost as long to see if log files have changed > > if you set your MAIL variable to that. So not just for email... > > This seems to be an example in point of a "niche" scenario, both in terms > of spread of usage (even then) and the fact that it's easy to get the > functionality by other means. > Yea... tail -f does it too... But this is a useful way to get your shell to tell you when something has changed. It's a widely used trick (or has been in the past). But it really has nothing to do with atime... Just a clever use of MAIL variable. > Again, I'm not opposing anyone from working on "relatime" if they > personally have a strong need and motivation. I'm not even asking for > removing the "atime" functionality, which can have its uses. > Yea, relatime has some interesting use cases: Is this binary / library in use is one such case. The fact that you've completely omitted that use case suggests that the analysis of atime's usefulness (or its lack) is at least incomplete. > What I'm saying is that, based on others' input so far, my own (long, even > if not as long as yours) experience and some late reflection, is that > "noatime" should be the default (everywhere, all mounts and all FSes), and > that working on "relatime" won't make any real difference for most users > (IOW, I think that developing "relatime" is a bad idea *in general*). And > I think this is a sufficiently reasonable conclusion that anyone with the > same inputs would conclude the same. So, if it's not the case, I would be > interested in knowing why, ideally. > relatime would work great on /usr/local where you have a lot of programs: you reduce a lot of traffic. It's quite useful to know what packages are in use or not based on when they were last accessed, not just last installed. I'm not sure this is a great notion to have everywhere. I think your analysis needs more inputs. Warner > Regards. > > -- > Olivier Certner
