From nobody Tue Jan 16 17:18:08 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TDwhG6c7fz57f3J for ; Tue, 16 Jan 2024 17:18:22 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TDwhG2PQ7z4k4F; Tue, 16 Jan 2024 17:18:22 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of bsd-lists@bsdforge.com has no SPF policy when checking 24.113.41.81) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 40GHI9rA085313; Tue, 16 Jan 2024 09:18:15 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Tue, 16 Jan 2024 09:18:08 -0800 From: Chris To: Olivier Certner Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 In-Reply-To: <6714298.qJWK8QVVMX@ravel> References: <2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com> <6714298.qJWK8QVVMX@ravel> User-Agent: UDNSMS/17.0 Message-ID: <9155214edb61b1bc3bad3bc96f96e22b@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4TDwhG2PQ7z4k4F X-Spamd-Bar: / X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [0.00 / 15.00]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; R_SPF_NA(0.00)[no SPF record]; local_wl_ip(0.00)[24.113.41.81]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+] 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