From nobody Sun Jan 14 22:29:48 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 4TCqhh6YcTz57K0B for ; Sun, 14 Jan 2024 22:29:56 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:7400:8808:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4TCqhh3t08z4PrH; Sun, 14 Jan 2024 22:29:56 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; none X-Catflap-Envelope-From: Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [209.250.224.51]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 40EMTmuo003131; Sun, 14 Jan 2024 22:29:48 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 40EMTmhw003130; Sun, 14 Jan 2024 22:29:48 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202401142229.40EMTmhw003130@donotpassgo.dyslexicfish.net> Date: Sun, 14 Jan 2024 22:29:48 +0000 Organization: Dyslexic Fish To: olce@freebsd.org, jamie@catflap.org Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 References: <2136329.mxFCRLsXLg@ravel> <202401111956.40BJuURB045685@donotpassgo.dyslexicfish.net> <3172137.KEUK7n9DnO@ravel> In-Reply-To: <3172137.KEUK7n9DnO@ravel> User-Agent: Heirloom mailx 12.4 7/29/08 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [209.250.224.51]); Sun, 14 Jan 2024 22:29:48 +0000 (GMT) X-Rspamd-Queue-Id: 4TCqhh3t08z4PrH X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:7400::/38, country:US] Olivier Certner wrote: > I've mentioned your answer in another response to Lyndon Nerenberg when developing a more general argument that 'atime' is generally flawed for these kinds of use cases (finding the last use, finding files to backup, etc.). It's true that the ability to deactivate 'atime''s implicit updates per-process would cater to more use cases, and it's an interesting idea. Essentially, though, you can't guarantee that some applications, or simply administrators typing commands at the shell, are not going to throw away your precious access times, so can't rely (in a strong sense) on them. Thanks for the heads-up - I've only now had a chance to catch up with the thread. You are of course right - atime can be affected by so many different things that it can't be relied upon. I just thought a per-process method would be a good compromise to avoid blanket atime changes across the system - both for atime usefulness, and I/O, but as you say, as it's unreliable to rely on anyway, this solution may be making things worse by giving a false sense of reliability. And to further bolster your point, whilst I have wished for more granuality with respect to controlling atime updates, for years I've run everything with noatime.. Even when I thought it was nice to keep atime relatively accurate, I soon realised that I simply never used it anyway! > Sure for backups and snapshots. I agree you'd better have backup perimeters coinciding with file systems partitions and use snapshots to get the smoothest possible experience. But snapshots alone do not guarantee the "correctness" of a backup (the ability to restart smoothly from it). Yeah, it's more like a snapshot at the time of a power failure, but of course, it's better than running on a live filesystem because a file may be missed completely if moved whilst the backup is running. But short of shutting everything down prior to taking the snapshot (I remember at last job some very old machines without snapshotting or decent db journalling capabilities being taken down for hours every night, so that the whole backup ran in a minimal boot environment!), I don't know of a cleaner solution... (though I'm sure some exist.. after all, live migrations between hosts are a thing these days.. I guess I need to do some homework on the matter! :-) ) Thanks again, Jamie