Received: by 2002:a05:7412:251c:b0:e2:908c:2ebd with SMTP id w28csp1563268rda; Mon, 23 Oct 2023 17:19:01 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG0UuPcvPGWzbvpMaJmz870NeztDUgzLc+tkL0ww7Xn+/lsLOtOAd6Yybohj6SpGuQjZh4k X-Received: by 2002:a17:903:41cc:b0:1ca:89c7:c7a1 with SMTP id u12-20020a17090341cc00b001ca89c7c7a1mr15610254ple.65.1698106741120; Mon, 23 Oct 2023 17:19:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698106741; cv=none; d=google.com; s=arc-20160816; b=Z7T6GSfA4Ld+VmwW3QSOqEF8eV3Av4/DzKw4B1AXApdSkcYvIqCY+ez18Ts72mKGvr GIRoJ8oyky36dlq5OHa5hvqWJcDTfm2ybqkbTTPedeE6Dx7sAIk8iR/EaMz0DfOS8ntF /lo1n+qip9rF2N5vZK7JJF64iucNQ/Bzo79zHHmvH+Zf150EETYQgwF28nncY6qhjJUS /UpT9DV0WvM1iT3+vTyALh2Qbkf/O9nHBKajzRGi+cw2c4jdyKlOM7CdPPb8vB5H5yHW 0FFuXOVOIMHJSHaATOWSdFSw193J6dya3l8XsectoQo37J5DJwyBcfb//WxTA1MtCAnW 2ScQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=iY8F6Fplz1VZOzDrso9gBBR3Wotc9sRtBic5aJbz6WE=; fh=cxbEGrbVUy6uMBdljNCkMp7CPA4sJJyaTvgwiYqXEy0=; b=Xvpzqn39CZoaSIyQ86TYx98HxB5RwRLf3mQliTz8fu+yb/EBtkuEI3nsbwG6H3NrWA OnB+ejtztZycP4wO53eL/GaHzZao1B6zAza9AjcDCwqYHlq7ATY/ESdiMl5MIrCUHnm8 iFckSzZ2lMDZk14G+Ot90kfT8AckyFWsOQdoRNVCObMkTBqPZzyLgkIYSrs2EtZUpSg7 XfLQNQMVzG0Axy0fy5ddtB939PyX0AK1oore6auLGMGtXVkjkM4Wsa1PLUPvpz5Y83Qq +YOJhukRXLvQW+qCt9GqtMbpA+M/SdvrP0JYD3bBhoJHqxe0FtaEVQwLF3j4BHOwC/A7 oCFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=NFkz4IY8; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id q9-20020a170902dac900b001c9ca0a03e8si7542375plx.68.2023.10.23.17.19.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Oct 2023 17:19:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=NFkz4IY8; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id A9B4580C1124; Mon, 23 Oct 2023 17:18:59 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231598AbjJXAS7 (ORCPT + 99 others); Mon, 23 Oct 2023 20:18:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231653AbjJXASz (ORCPT ); Mon, 23 Oct 2023 20:18:55 -0400 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40F7111A for ; Mon, 23 Oct 2023 17:18:53 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-507b18cf2e1so5340140e87.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=1698106731; x=1698711531; darn=vger.kernel.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=NFkz4IY8yN89v12HPfLxH+qlwrs2qNUsUulQ5ZRSJHMsg3pU5tq9gXsABmSrkxlrZd +cRzmR+NOKzFXMaXPlivzyfHFXat73apu1eFNdnDXH/Jv4LOkb2G1Qk1OMkR5mP7BlgM pFm3IGzM7xd1KOPF2yN8/pws6EU2LMbNoCyFE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698106731; x=1698711531; 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=ENedbSn0SA+i5t0bQfjQ7La2DHjT9eE2vMTRTADm1zLASS0ZuJvaOKXfGkObl534tJ SU6PNkl50e5VhZi8C5oPvAxPfxr8VKoESLKMuBXnDqZOPrDYN2Mzts7KvbP8j3pBnAjy /VqUVCTSq1iOh+K19yw2Gl7eClGsm9CX9vJB3yHBLTayjYHgB9fjGHwOX2ZGPSBlaZm7 usR/+R0A7LhTCQ5NmQBcrhnTSWDXxuMjYYnaB94kswRuxA0/MPtF91nc+NlNSf1xBLIL mXTQEjm6OnDS0BuF4elGFc6hXAj6nFXLEg7LGlQ9XQYLzvyLFbS7oGZy1/LTe0GOMMS9 oEcA== X-Gm-Message-State: AOJu0YzgklB/zdKtUr/+na1/0p4jGZclT37xIag1KMZLI947C4MjjsdU F7JsSCZxGNjFY7UO21drP6sB+8vowO/jFfmUILFTeQH2 X-Received: by 2002:a05:6512:60f:b0:500:b63f:4db3 with SMTP id b15-20020a056512060f00b00500b63f4db3mr7481417lfe.35.1698106731174; Mon, 23 Oct 2023 17:18:51 -0700 (PDT) Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com. [209.85.208.43]) by smtp.gmail.com with ESMTPSA id b7-20020a1709062b4700b009ade1a4f795sm7207101ejg.168.2023.10.23.17.18.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Oct 2023 17:18:50 -0700 (PDT) Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-53dfc28a2afso5698459a12.1 for ; Mon, 23 Oct 2023 17:18:50 -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-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 23 Oct 2023 17:19:00 -0700 (PDT) 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