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 45E32C00A8F for ; Tue, 24 Oct 2023 18:40:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE7326B02DC; Tue, 24 Oct 2023 14:40:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A96A46B02DD; Tue, 24 Oct 2023 14:40:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 95F946B02DE; Tue, 24 Oct 2023 14:40:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 86E746B02DC for ; Tue, 24 Oct 2023 14:40:14 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5E8764049A for ; Tue, 24 Oct 2023 18:40:14 +0000 (UTC) X-FDA: 81381219948.21.30F82E7 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf04.hostedemail.com (Postfix) with ESMTP id AD5D44000E for ; Tue, 24 Oct 2023 18:40:11 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aR5dfj2B; spf=pass (imf04.hostedemail.com: domain of jlayton@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jlayton@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698172811; 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:dkim-signature; bh=Xe0wF7mgvmZCFWwP7fcGH+Eub1oED/IAnnGG5PkQ1xU=; b=2b8cJV9EcvNIAto/a0FbtsYBtOqvSjyeJH9BxlD3u4YJT7MofPiu3+k+iP+fwikvlKRwf4 cXOFWK33pMXLifYgSbHZ7K0LER7y8S5D9qtsHitr0lr3wR7ORa/XmMj2pM+jLb3Ww+5KpT 4KxjeTE144pZ3AdQc9S+STt/BSt+sw0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698172811; a=rsa-sha256; cv=none; b=T9zGN5mXq3rrhMD8DiJlo4SBv0bqFbbn9+IFAbT9HkuxN+NxLlvYH6eGZ/iCHPDaz38DY5 3WWWn38KbKqGBIeMFH8g1r3MBczDmKpR9SX7UY/a93nJvu+qiDozfWT/NQaZqqVEUCstmY 6k9XNUzIfzMuDXNeZbSu0bkD0ORbtKY= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aR5dfj2B; spf=pass (imf04.hostedemail.com: domain of jlayton@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jlayton@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 81FDF62C25; Tue, 24 Oct 2023 18:40:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E8B1AC433C7; Tue, 24 Oct 2023 18:40:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698172810; bh=Xe0wF7mgvmZCFWwP7fcGH+Eub1oED/IAnnGG5PkQ1xU=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=aR5dfj2B+9L9WTja+3SyJ8WB9QMgZo4R+vxoFDhQoAUL1rtUOh+Oh5Q8DQmdfVTO4 yGp5tE/69QdXH5HxMqJHG7wcibIkHLtTyOezwvPMxpAm86wk65poIE/uewxy/Ie6v3 hSHpwvYzQ6e9UEWsvO3SaWQYijZfMxf09CUdubjLB4ttXC80RueJZB863KJ470NSzB NMRpUvxtODKii5ufHHS1e4VgM9qMeTvQltU7KO0D7dMhAnpxAiASNlUi/neKfJiDK+ xe5dn9XSPdXwMQCwnpFDi/Iua7ZyggSyeH4EgK4Vnte8CUNiPzFVJE4c5FjHvkEK1O cyliPAfxW2aoA== Message-ID: Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing From: Jeff Layton To: Amir Goldstein , Dave Chinner Cc: Linus Torvalds , 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 Date: Tue, 24 Oct 2023 14:40:06 -0400 In-Reply-To: References: <5f96e69d438ab96099bb67d16b77583c99911caa.camel@kernel.org> <20231019-fluor-skifahren-ec74ceb6c63e@brauner> <0a1a847af4372e62000b259e992850527f587205.camel@kernel.org> <61b32a4093948ae1ae8603688793f07de764430f.camel@kernel.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-Rspamd-Queue-Id: AD5D44000E X-Rspam-User: X-Stat-Signature: kjwnoa7zhbdtji51q34ii79c3s1j3zp1 X-Rspamd-Server: rspam03 X-HE-Tag: 1698172811-792371 X-HE-Meta: U2FsdGVkX1//qU8BBlT3C0PSWaOs20Ie+7Fwi9jYzu4ChA7N7k3gIYJ4S8Q1Znm55c9zAUy2FGEeSWttD4KFKj0iDjv8N8dCSGsiRInlr8kRfi05GwIcKFQmxAAmXGxxhom3ntsrGFJpNEh5d68L1ADMNjAlf/7mbvgfYoa7qDA0F0eKs3lJPs8bLFJxeapIpAkPKJh8iRB8R4A/aFnBBoSZz/BfvaVRSb+3Qscv1rXlWmUlU6/PbncELK+ecYSSUDqc2H9zjxn2we0NITeILiAH5C8xHB+pD7+S7NO91j6woLNZmuQ57kZshcL6KH3t/eVRetlLN8n4U+tDdM+5FJqaV6CDdXhp4LKyGwXwya8r1zfrv+NJAoixjdmbgOutZ/bWhNB/7ZSU0jBxvLYDgoXaYYZdtJtwSQR87tqpBWU+N0i9LKiArBTHIcq84o3Zz5Eq654pt2LPLjCfT4EH0mF9H3cV7s5ehwDfjkLxqMwOMyEe2W5YIOSppgWv/6E/Y5LYSwRyYljNA/gmKKEhFV+0L85Eprg8U8NJEzKpy9THnZpieg0fceRXvDl6r5y6Cdx1MEXnKSahMdDvVUhgGTID+K6flkE3b+VVImDzm3FKr0sysk24f/6DcQlY2UDvC6FyxtWk8QB3SBoQmd2vlaWOfkUX7pjKT7s+FQ/f5/xZbg3XyTjaEVSexyznm/PYtORxTyqRmvwoW4ILgD3mYj1Pvg/T/yd39WZvB2YfAdyLs+0c2iAGq7dWDfd3Drr76bXrt0MCnWiPrVVinJJrMxzeqr5ycPCuTEEAZF2Ia/Aj7K4Tb7d2Eld7BbPcGdgRObXEZ64VA8DRD1Ameuh574rqC+8dyxrTm/zk5a+kT/qNh97JHnt0mUNjb9xVAGLLtZlackSob/sJj4/kUHfCvZSDHPRttpnE+karVDHU5JVeCCUWUGO+dmXkxHcV26LVnZJACYttVdaNPC9PNwt izmrnHQN AZaJE8M+S4GN7opq9yGBDpIDO+QmmbHE0fL3kUO5ahMtkopKxC/apzpbfWxjMIqScy4q+d4HsAK8LlepPYR+0AwrA+oYWWkZe8Wzi1gP/ogi66FEFwP8GEeAShsrvlZs4NML3koQtlOLpyN5HAWnvfXFj0Brdzo97EG6vO6alIxjX0TTTwtvFuZ6QC3u71ffgdkwMtsz879nHypSYvCkfM8GG4KbAcyfAwUCqNPlV1UFbegijwtXIjId9z9sDBNhBBh3s2MHuh2v1ArSR6zab8QEezShRO+fIiDkESlc/5h1QFOYbrKTxKR8Ffg== 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: On Tue, 2023-10-24 at 10:08 +0300, Amir Goldstein wrote: > On Tue, Oct 24, 2023 at 6:40=E2=80=AFAM Dave Chinner wrote: > >=20 > > On Mon, Oct 23, 2023 at 02:18:12PM -1000, Linus Torvalds wrote: > > > On Mon, 23 Oct 2023 at 13:26, Dave Chinner wrot= e: > > > >=20 > > > > The problem is the first read request after a modification has been > > > > made. That is causing relatime to see mtime > atime and triggering > > > > an atime update. XFS sees this, does an atime update, and in > > > > committing that persistent inode metadata update, it calls > > > > inode_maybe_inc_iversion(force =3D false) to check if an iversion > > > > update is necessary. The VFS sees I_VERSION_QUERIED, and so it bump= s > > > > i_version and tells XFS to persist it. > > >=20 > > > Could we perhaps just have a mode where we don't increment i_version > > > for just atime updates? > > >=20 > > > Maybe we don't even need a mode, and could just decide that atime > > > updates aren't i_version updates at all? > >=20 > > We do that already - in memory atime updates don't bump i_version at > > all. The issue is the rare persistent atime update requests that > > still happen - they are the ones that trigger an i_version bump on > > XFS, and one of the relatime heuristics tickle this specific issue. > >=20 > > If we push the problematic persistent atime updates to be in-memory > > updates only, then the whole problem with i_version goes away.... > >=20 > > > Yes, yes, it's obviously technically a "inode modification", but does > > > anybody actually *want* atime updates with no actual other changes to > > > be version events? > >=20 > > Well, yes, there was. That's why we defined i_version in the on disk > > format this way well over a decade ago. It was part of some deep > > dark magical HSM beans that allowed the application to combine > > multiple scans for different inode metadata changes into a single > > pass. atime changes was one of the things it needed to know about > > for tiering and space scavenging purposes.... > >=20 >=20 > But if this is such an ancient mystical program, why do we have to > keep this XFS behavior in the present? > BTW, is this the same HSM whose DMAPI ioctls were deprecated > a few years back? >=20 > I mean, I understand that you do not want to change the behavior of > i_version update without an opt-in config or mount option - let the distr= o > make that choice. > But calling this an "on-disk format change" is a very long stretch. >=20 > Does xfs_repair guarantee that changes of atime, or any inode changes > for that matter, update i_version? No, it does not. > So IMO, "atime does not update i_version" is not an "on-disk format chang= e", > it is a runtime behavior change, just like lazytime is. >=20 This would certainly be my preference. I don't want to break any existing users though. Perhaps this ought to be a mkfs option? Existing XFS filesystems could still behave with the legacy behavior, but we could make mkfs.xfs build filesystems by default that work like NFS requires. --=20 Jeff Layton