Date: Tue, 16 Jan 2024 09:18:08 -0800 From: Chris <bsd-lists@bsdforge.com> To: Olivier Certner <olce@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Message-ID: <9155214edb61b1bc3bad3bc96f96e22b@bsdforge.com> In-Reply-To: <6714298.qJWK8QVVMX@ravel> References: <ZZqmmM-6f606bLJx@int21h> <CAGMYy3vsSD7HHtGxYXJn%2Busr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com> <2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com> <6714298.qJWK8QVVMX@ravel>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9155214edb61b1bc3bad3bc96f96e22b>