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 22DBEC25B67 for ; Tue, 24 Oct 2023 00:18:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F9436B015E; Mon, 23 Oct 2023 20:18:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A95B6B0166; Mon, 23 Oct 2023 20:18:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 871296B0167; Mon, 23 Oct 2023 20:18:56 -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 757276B015E for ; Mon, 23 Oct 2023 20:18:56 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4E2181A05C8 for ; Tue, 24 Oct 2023 00:18:56 +0000 (UTC) X-FDA: 81378444672.27.ED5FB6A Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by imf22.hostedemail.com (Postfix) with ESMTP id 44B0BC0013 for ; Tue, 24 Oct 2023 00:18:53 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=EgIlZy24; dmarc=none; spf=pass (imf22.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.46 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698106734; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=iY8F6Fplz1VZOzDrso9gBBR3Wotc9sRtBic5aJbz6WE=; b=lc5sdwL2E7ZTibFkxchGB06IkB6QMZJdgOnT77GujwO5jUpiuNxds0iMqPm183CKF/dUpL iFUQpSy4S5X41diY3bNrABuk/DBdXatpM0HRkSVSCmiWSVuw5/frBbBvq3PKwnkXhafRK6 pHKoDf0+c1ydVaVTSZTJvTokBq3vqHc= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=EgIlZy24; dmarc=none; spf=pass (imf22.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.46 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698106734; a=rsa-sha256; cv=none; b=MzyKvMC6ZS4TRgZo6r5lEZakmLQz4WMya9neLDW5tyAh7zIhNCjST/oREfRFghRdfJ+7oV JOMrnHFSkrkWiRWcCtqfYvkk1Ow4TdrJkYmBUw+S2FfJ/KrdUCCoY3IfjnEywTAp9a8NDJ ZWQlSy89dm6AxEbhRezgFo3zXPazwE4= Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-507b18cf2e1so5340154e87.3 for ; Mon, 23 Oct 2023 17:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1698106732; x=1698711532; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iY8F6Fplz1VZOzDrso9gBBR3Wotc9sRtBic5aJbz6WE=; b=EgIlZy24Q52y+Y01qOaC0M3H3uXPXWWbmDS4fOP0VbQOUvA4dqHk7Rp46cACK51ija Oc9MFEU6oNeFz+lZLIQ5w2k6kppWIdI9ZcD1m7+ScqXmghTCdleDxVzmxYPkQrTkfqGH XmOHKwZQ6yJoQ/gN2JgCZv/aHTeCUSVDDZQUU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698106732; x=1698711532; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iY8F6Fplz1VZOzDrso9gBBR3Wotc9sRtBic5aJbz6WE=; b=PkffASZ8i5OOXFyCEYZ9vvrYd6uyp0itFo/Tyf/GWRIbL+5hdJHj9Jyi5bwm+pH/jL T2Fw4lawSI+WU5pj1rV9/rV0jufF2i3q0hG9dJA3QfdUF+HszHTV3clYHgpllA61qBx0 yd5TbpknI3roNrWI+/MpAe21Ym5Pneaq6T1VnmxUEC6f3JHhaugCSLIHs46v01xdqTI1 qHis9wS0/SIHL/8RzKgX18h1P1wdmbI0ZHHwaB1ZBOIVXRDJu9Daz7or0LM9gRfGuJcT FjtTl6xhC94jOv0l4Zf29ot1tkvamK2Tf2iVsHRJyDgqaWGfC9P7TXyAE/o9XQ9UIHNh MFrg== X-Gm-Message-State: AOJu0Yz1vY9+7mFoQo7V3DDFqgYyGX9yjtWx+pyrhk4hMdIaReRyop6N 9E+5y1TGnEqDhzZfk1qDCckV9MszEiZRPB6A4n9vU5PT X-Google-Smtp-Source: AGHT+IF3+Gr6icW8+g/Nc80OR7eecwvTvwyr8hTQ6wGNGXjq+u99e0pdpgmeqfIvgUyHnrzqi4TSTA== X-Received: by 2002:ac2:4287:0:b0:506:9c0a:17d9 with SMTP id m7-20020ac24287000000b005069c0a17d9mr7810315lfh.40.1698106732100; Mon, 23 Oct 2023 17:18:52 -0700 (PDT) Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com. [209.85.218.46]) by smtp.gmail.com with ESMTPSA id j8-20020a50ed08000000b00533dad8a9c5sm6972381eds.38.2023.10.23.17.18.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Oct 2023 17:18:51 -0700 (PDT) Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-9a6190af24aso618506466b.0 for ; Mon, 23 Oct 2023 17:18:51 -0700 (PDT) X-Received: by 2002:a50:d795:0:b0:53e:467c:33f1 with SMTP id w21-20020a50d795000000b0053e467c33f1mr8315209edi.8.1698106710154; Mon, 23 Oct 2023 17:18:30 -0700 (PDT) MIME-Version: 1.0 References: <5f96e69d438ab96099bb67d16b77583c99911caa.camel@kernel.org> <20231019-fluor-skifahren-ec74ceb6c63e@brauner> <0a1a847af4372e62000b259e992850527f587205.camel@kernel.org> <61b32a4093948ae1ae8603688793f07de764430f.camel@kernel.org> In-Reply-To: From: Linus Torvalds Date: Mon, 23 Oct 2023 14:18:12 -1000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing To: Dave Chinner Cc: Jeff Layton , 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 , Amir Goldstein , 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 44B0BC0013 X-Stat-Signature: t4qceuqnemdg9jsbhybij31enc44awo8 X-Rspam-User: X-HE-Tag: 1698106733-337050 X-HE-Meta: U2FsdGVkX1+RsFm1wLIzExbclr+RvjMGDM3yh54SmolgnGBgTNcdb84r+BgLpFyYt84yxUVse21cHgTzlIO8fI83hzG0QwSTJ81cHUL0Jl9VNlAFsQlPyB6C6FNSbhJEw6O/S6RtzN5kkKC5eBBMvhYQ0WtHuHLEeXR5lnrcpYm2+F6rIlkeK/lOfjQE0r4Dnn5wshMzsRH+UVIOUFEzIUQrg2Lqz7Bc1gIEhnE/zK0ymGmYrNZEwYvtI/HWc72nTQN4w5Zenx+WpBnPb7En/uqNoCr+gxhTBnInDJGvxX7gOosF6xDhRaq2Rl7t45mMWyvQLVfRH3XYxpf1eZF5bw4kHOex1yru19lZdjkuXEGPYvgVCad34/bMUgF4Smp8FrNve41chokoOkEihJVeOF0VSHLatbfVFP96kMScSQZI3+YeWNwS6ff3G6S+GMWHjgfKamOZ3CH6RfxaQjl3yy4hcTvauMFCDYQo/0961bmj4ZODaUhtT1ULkETXW1suGvBJg+kZz+71OPMxNBbsUW0ElolziOdrXeObGi7dB7p0XsgqdEpg7pmBEL97Mp1VTRa0t/C29pNnJKeCkfp2Y+2CDxiKloazHW3GmuVv4Ey+BFSNwlJmsv9tSXrpkGQGoH7i/+3U10YCilK6K7yTr13FAGxZjQ2L3yWl1VLdlFNnNMpl+NfbmvTfvuibH/B2E7Jxju9Cipep/3Qu6wWF79q6ahtd5GDCqhs+MqA6q+jjAf1AGX1qPeyMyA0HWTTiOCaZj7xHZVZwkzkzrSf6DDgb3chEiRnSn7ObROHVMRTk5IJviILTNLKACSN8PTQjszymnYVQJ0UsW/TigVawLi7+c+8i4RX1VfG46x8LSaqzl0HkkiKXpX8/60M0Qgar/k02E/H3MAT0wDAaTe0Var4zxjUMHt8+VaG/htDA0rVQQ4a1fabNxoDensZH7Oqu5l9H5/a/VQ+GttnOufW PsJwT/dQ GL8grbRcdn4ajfdJGmmCuDSO9CWiORULZKNJouV0KBgtCOjxwlJmbt95La1+jJHGULdBFsVCnz0HCTyFCA5JEeNl4Flen4kZphVZZPFn7dSmLg0bmZr3dhVidTwo9PBx/PTGYOpl30CW+pK/5OB+R0IJlhogjdl30+TwTPWhF9hd3uiP1hmd8NvIrawLVE8opwJFE8CXzn3QabVq4HEswiErkO1Wa6KtrJm6qbYSMKeOdaWdqyt1i8ByYzOxxXdddeEPyLVVkGHJ8MK67TqyEuZYjhd5F83tqBArLbIjQHURFzvG7ltddnheGd6stwC0EIuWvhZAvTgTHSVGNpD9j0F9dZWRabf72uv7fdWbEBJWlEjQg6pYONBqRrNN1z56eb+SVyxQnV8uoAID0U7P58LnAIkWV4grAoYMgw7KSisTBAdoSY7TjdGmuoXkkCngZVa0LMZy11bdcXpWNSnGq2zb09vR7XyC3dABF6ywboiFxpg6KgBjpYD/k+03SSmkLwGMj6UJKWoWfhlfnCRKcuyo6/wgWh2sDFQeGNdmE1di+GMB5C2ul/LFmsQ== 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 Mon, 23 Oct 2023 at 13:26, Dave Chinner wrote: > > 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 = false) to check if an iversion > update is necessary. The VFS sees I_VERSION_QUERIED, and so it bumps > i_version and tells XFS to persist it. Could we perhaps just have a mode where we don't increment i_version for just atime updates? Maybe we don't even need a mode, and could just decide that atime updates aren't i_version updates at all? 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? Or maybe i_version can update, but callers of getattr() could have two bits for that STATX_CHANGE_COOKIE, one for "I care about atime" and one for others, and we'd pass that down to inode_query_version, and we'd have a I_VERSION_QUERIED and a I_VERSION_QUERIED_STRICT, and the "I care about atime" case ould set the strict one. Then inode_maybe_inc_iversion() could - for atome updates - skip the version update *unless* it sees that I_VERSION_QUERIED_STRICT bit. Does that sound sane to people? Because it does sound completely insane to me to say "inode changed" and have a cache invalidation just for an atime update. Linus