From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5EA89C4332F for ; Tue, 31 Oct 2023 19:43:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6BB666B02FE; Tue, 31 Oct 2023 15:43:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 644266B0302; Tue, 31 Oct 2023 15:43:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E59A6B0304; Tue, 31 Oct 2023 15:43:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 40D2E6B02FE for ; Tue, 31 Oct 2023 15:43:10 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 1CAB5A0404 for ; Tue, 31 Oct 2023 19:43:10 +0000 (UTC) X-FDA: 81406780140.22.674CB30 Received: from mail.stoffel.org (mail.stoffel.org [172.104.24.175]) by imf11.hostedemail.com (Postfix) with ESMTP id 642BB4002E for ; Tue, 31 Oct 2023 19:43:06 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=stoffel.org; spf=pass (imf11.hostedemail.com: domain of john@stoffel.org designates 172.104.24.175 as permitted sender) smtp.mailfrom=john@stoffel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698781386; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V2+m98TjCjNJvUhtdVk5jnySpXcmi9OaDapxiYjOhLs=; b=eMrzB2huoe/32M5coetZQTf8og+yd2REohHsTDRRbe6fmOGOOAelNDALSksMtJDyfzli7N 1R4k5KzTL5yZzVrtivYmoHaWpS4S+aAR1iRUkh7nVWE0ZMLX713/g0mWo7FL+KfsBCkdmf 2IUsKNY/jmjRWF+35ckMaU1HK4jRZjQ= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=stoffel.org; spf=pass (imf11.hostedemail.com: domain of john@stoffel.org designates 172.104.24.175 as permitted sender) smtp.mailfrom=john@stoffel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698781386; a=rsa-sha256; cv=none; b=GPxSNxdNqK8/TTixA7zb3qFah/nIcNgTeziyRFhhezl11Fh8SgRhoHstYVm3bmwHolicTl tcLov5VsSLtuiSFK4L5ollLzPgecFUeRKqtU26ee3e6qTND8X4iG+X57NtlAUQoGr6zcp3 xKkmoiRCjmUan+2n+EnP9s/DW2SJAOo= Received: from quad.stoffel.org (097-095-183-072.res.spectrum.com [97.95.183.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.stoffel.org (Postfix) with ESMTPSA id 5EB591E12B; Tue, 31 Oct 2023 15:43:05 -0400 (EDT) Received: by quad.stoffel.org (Postfix, from userid 1000) id 80C85A8B01; Tue, 31 Oct 2023 15:43:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <25921.22728.501691.76305@quad.stoffel.home> Date: Tue, 31 Oct 2023 15:43:04 -0400 From: "John Stoffel" To: Jeff Layton Cc: Dave Chinner , Linus Torvalds , Amir Goldstein , Kent Overstreet , Christian Brauner , Alexander Viro , John Stultz , Thomas Gleixner , Stephen Boyd , Chandan Babu R , "Darrick J. Wong" , Theodore Ts'o , Andreas Dilger , Chris Mason , Josef Bacik , David Sterba , Hugh Dickins , Andrew Morton , Jan Kara , David Howells , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing In-Reply-To: References: <2ef9ac6180e47bc9cc8edef20648a000367c4ed2.camel@kernel.org> <6df5ea54463526a3d898ed2bd8a005166caa9381.camel@kernel.org> X-Mailer: VM 8.2.0b under 27.1 (x86_64-pc-linux-gnu) X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 642BB4002E X-Stat-Signature: gcz5tyjdpcrqmdmi8kz5r96w98fc9xcp X-HE-Tag: 1698781386-141363 X-HE-Meta: U2FsdGVkX1/F7RNv4SCbcWJI4g3G9rjXBxZjTOqo4Jp851q53h9baH7bWEjjGKGjn80hm8aFYPaGneMnW/WXl9etUfn7I2udREgZI+L2LOqSktpztjQKsusuIsHUZCe0u7Etp3WsZFGGPZj2v5AQ2S0GGn8BVXkA6n6j2aWnkL+ZZsCaznyZM9D9N1OzGrzVAOWP/U/nLoc9N28Gj0g44EB2pHyKiTCJzot4P6NmJYejoCvZTdIeh5/18sULNUwhtsWj5N20sjaYfuL3icKtwXlQHX9Z1KMEMp1CTU1ScGYr9l49ewcseUtVADkIY0U/Jw9jn2cAn64xFNl2Z1WzqSOX/Xzeh/Shgq9GYQmAVYsudUScLUAjE12kRWKoU8z8jTpPtxAWS3nV42J6zvIjc0RxUdn8xqhzSj2rnoWYrLy7ThATr5dBYXLulcZ2g9MC4HvNaeTfltgG1d+4RPadtHO7zo5tEVwNPuOGDEPDXQblVoSuT+jVidI2uQ5aKaq/g+PAno6DXNcJhangefME/Fdjavd7CgBcYY5GdbPJyeUsGdMOBSLBBy0MFSxTvkDSVDwyU0RmC2Hk6671sMk3kfA8yYdxJ2cDUTV+XllsIAidOAgg04L0RhONJypYCfLl4bovhXUJ7IAWfrk3hp4DlI/VMyvR9K6TraFVOl+ZdU7WcFXb+GiZfQNd/WeCgHVexw8I1oNHnHwtGr9YiQ2ArnoSvoLi32q2utzKJJ65BqMwLRPtd06wyz0mMd96GotLqaESE/pLs/hIXwy1+49nqrMSCT+lWdkGz2xOxHEI7K/reV18LHF1XuSzdKgfMLftJcrAzym5j51HK11HLiW5sN8egtRBxZ21Q7HZK0tMMrX3WO99QEIebj7Tiz2mgrAGgV/v/DXKVxB9eHO1c4iVChZ6HTbhzDnYW1wW0i3RU4KVT+M6DWzs+B51ienF89w5CPzyxF5CVdbfJ12PV/R 36jWihij g3wIzPe1VjHJ5+fyTxfvrBkVEyAbQHsIQjV47Rzq/ahSEdLepgpNIl25qPb++fm86E1DTaaTkMPSvVxTswG9ZLijsWtDcqwUV84BsX6+4+5aKZi1/9bs7Y/qwp97glqcoxcGliJ4x9A+L0VDoPgCgXp50pwotCpCxbbycTddira9LBHP1sIsv1laEbHi9ZjR8SgoE X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: >>>>> "Jeff" == Jeff Layton writes: > On Tue, 2023-10-31 at 12:42 +1100, Dave Chinner wrote: >> On Mon, Oct 30, 2023 at 01:11:56PM -1000, Linus Torvalds wrote: >> > On Mon, 30 Oct 2023 at 12:37, Dave Chinner wrote: >> > > >> > > If XFS can ignore relatime or lazytime persistent updates for given >> > > situations, then *we don't need to make periodic on-disk updates of >> > > atime*. This makes the whole problem of "persistent atime update bumps >> > > i_version" go away because then we *aren't making persistent atime >> > > updates* except when some other persistent modification that bumps >> > > [cm]time occurs. >> > >> > Well, I think this should be split into two independent questions: >> > >> > (a) are relatime or lazytime atime updates persistent if nothing else changes? >> >> They only become persistent after 24 hours or, in the case of >> relatime, immediately persistent if mtime < atime (i.e. read after a >> modification). Those are the only times that the VFS triggers >> persistent writeback of atime, and it's the latter case (mtime < >> atime) that is the specific trigger that exposed the problem with >> atime bumping i_version in the first place. >> >> > (b) do atime updates _ever_ update i_version *regardless* of relatime >> > or lazytime? >> > >> > and honestly, I think the best answer to (b) would be that "no, >> > i_version should simply not change for atime updates". And I think >> > that answer is what it is because no user of i_version seems to want >> > it. >> >> As I keep repeating: Repeatedly stating that "atime should not bump >> i_version" does not address the questions I'm asking *at all*. >> >> > Now, the reason it's a single question for you is that apparently for >> > XFS, the only thing that matters is "inode was written to disk" and >> > that "di_changecount" value is thus related to the persistence of >> > atime updates, but splitting di_changecount out to be a separate thing >> > from i_version seems to be on the table, so I think those two things >> > really could be independent issues. >> >> Wrong way around - we'd have to split i_version out from >> di_changecount. It's i_version that has changed semantics, not >> di_changecount, and di_changecount behaviour must remain unchanged. >> > I have to take issue with your characterization of this. The > requirements for NFS's change counter have not changed. Clearly there > was a breakdown in communications when it was first implemented in Linux > that caused atime updates to get counted in the i_version value, but > that was never intentional and never by design. This has been bugging me, but all the references to NFS really mean NFSv4.1 or newer, correct? I can't see how any of this affects NFSv3 at all, and that's probably the still dominant form of NFS, right? John