> > 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.
Yes, but I never pretended to have completely analyzed the usefulness of 'atime'. See "which can have its uses" above. But I think there is already enough matter for the case of the *default value* for 'atime'. > 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. Both the examples above prompt some straight objections on the current usefulness of "atime". First, unless you've disabled building the locate database in cron (enabled by default, on a weekly basis), access times on directories lose most of their usefulness. Second, if using an IDS, I'm afraid it's just game over. And even if you think you are not, '460.pkg-checksum' at least is readily there to much complicate, or even prevent you from, getting package usage information this way (it is enabled by default, and on a daily basis). The general point here is that a single access time is inherently fragile to interferences by multiple applications for multiple reasons. > I'm not sure this is a great notion to have everywhere. I think your > analysis needs more inputs. May be, but to me the case for the default value debate at least seems quite strong already. Regards. -- Olivier Certner
signature.asc
Description: This is a digitally signed message part.
