Hi Lyndon, > > I've never found any compelling reason in most uses to enable "atime", > > except perhaps local mail (snip).
> When UNIX ran on PDP-11s and disk pack sizes were measured in the > tens of megabytes, atime was very helpful in determining which files > were likely candidates for archiving to tape when the disk was > getting full. I appreciate this kind of historical information. According to Wikipedia, most of the PDP-11's lifespan after my birth date overlaps only with my childhood and teenage years, and I had never the chance (or curse, I don't know) to get around to one (actually, I only learned about its existence years later, much after after its phasing out). This purpose, i.e., "determine which files to archive", was achieved by relying on 'atime' I guess by selecting those whose access times were the oldest (perhaps combined with other criteria). The mean employed here is exactly the same as for the use cases reported by Warner: Being able to know which executables / libraries / packages are effectively used. So this approach has exactly the same problems. As I explained in a response to Warner, it is currently almost unpracticable on FreeBSD, because some periodic processes mess up with the access times (for more details, please read it). But more deeply, as sketched in that response, the problem is "general": Relying on access times is bound to be fragile, simply because they are updated implicitly, without the applications asking for it at all and for most neither being aware. The use cases presented for 'atime' so far all assume that the access times will be updated only on some action that is relevant to their scenarios. But you can't prevent other actions not in your scenario from updating these access times, and it can be very hard in practice to predict which can occur on a given install (depending, e.g., on how many software packages you've installed, their provenance, etc.). In some answer, Jamie Landeg-Jones suggested to have a per-process flag to control the implicit access times update, which is a workaround that is probably enough in some use cases, but not for all (see my response there). At the same time, I'd like people to realize that it is still no more than a workaround, or a "clever" way to solve one's problem in particular circumstances, but is not a generally reliable solution. What I'm evoking here concerns more the "usefulness of 'atime'" discussion than the "default should be 'noatime'", but has non-negligible bearing on the latter. > And in the Usenet days it was common to mount > /var/spool/news noatime, which eliminated a *lot* of meta-info > write traffic. A logical, completely predictable move. > These days, other than /var/mail, I can't think of a compelling use > for it. I've been running my Plan 9 systems with atime disabled > ever since fossil arrived (decades) without any impact. I agree. That's exactly the reason why I wanted to seize the occasion of rob...@rrbrussell.com's question to present my take, because I had been wondering about that a few times in the last 5 to 10 years and also never encountered a compelling reason for why it should be the default. And I insist: The initial discussion, and my main focus, is about 'noatime' becoming the default. The discussions about the usefulness of 'relatime' and 'atime' are very interesting, and I'm even participating to those, but to me are secondary in the end. The usefulness of 'atime' is of course in part connected to the default to use, but they are still very different questions. For example, concerning the former, the frequency of needs (how many uses?) is not very important, whereas it matters a lot when it comes to which default to choose. > I don't see any issue with making noatime the default. For those > that must have it, /var/mail can be carved out as a distinct > filesystem and mounted appropriately. The summary of the technical side of this discussion so far is that there most likely won't be any issue at all for the vast majority of users if 'noatime' becomes the default. We'll see if more reports for other scenarios are to come (or if we can find or guess some ourselves; irrespective of whether they validate or not the current evaluation). And, as reported by others, even /var/mail should not need it in most uses given that all prominent MUAs have long departed from using the access time comparison alone. (I won't pronounce myself on this since I'm not personally using them, but I'm not seeing any reason not to trust the reports. If some people have contradictory facts, I hope that they will present them.) Thanks and regards. -- Olivier Certner
signature.asc
Description: This is a digitally signed message part.
