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 D1B9BC00A8F for ; Tue, 24 Oct 2023 07:08:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 72D5A6B0185; Tue, 24 Oct 2023 03:08:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6DE056B0186; Tue, 24 Oct 2023 03:08:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A5E76B0187; Tue, 24 Oct 2023 03:08:42 -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 4BC906B0185 for ; Tue, 24 Oct 2023 03:08:42 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 10B6E1A0DF5 for ; Tue, 24 Oct 2023 07:08:42 +0000 (UTC) X-FDA: 81379477284.01.0D67D29 Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) by imf24.hostedemail.com (Postfix) with ESMTP id 5782E180006 for ; Tue, 24 Oct 2023 07:08:40 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RxGSDWqI; spf=pass (imf24.hostedemail.com: domain of amir73il@gmail.com designates 209.85.219.51 as permitted sender) smtp.mailfrom=amir73il@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698131320; 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=SqdvkUsqWd4zu3IEIRbwUNktCPDbd/gk6A5nLT4VIeM=; b=CQ7ONlOLpWNCHv6Xl80CLJMF0sWGcve3kodnNzEMJShWisNQ4LkxLbA3B8Lyp5og+9ME/0 u8UC7VxRiUfhXMzM7DT/LMOQN8nhZREV1m3tiObfY1uuY6W9/cVSaHZODy28lB7Ehbk24X NKTZqjYIZqXmsaVvpwTR3/TJINuwUMc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698131320; a=rsa-sha256; cv=none; b=JjltuFfdI6p0L/WzT5PPYIkjZd41Yg5WT2Z7KNJYCEMP+1FeZFfIaZO9roOAVQptj6oqfm U+/JATgxuPVeq5pUThg+kT+WbgxBAiodm4DHPv1j1jsxh4UKmfaY+kSYf4/+HCvjj8oVXK pVgEM7f1wBsYyyfAcST3pfKN4bRF/7Q= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RxGSDWqI; spf=pass (imf24.hostedemail.com: domain of amir73il@gmail.com designates 209.85.219.51 as permitted sender) smtp.mailfrom=amir73il@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qv1-f51.google.com with SMTP id 6a1803df08f44-66d0ea3e5b8so28240486d6.0 for ; Tue, 24 Oct 2023 00:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698131319; x=1698736119; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=SqdvkUsqWd4zu3IEIRbwUNktCPDbd/gk6A5nLT4VIeM=; b=RxGSDWqIn7WA/UwfDmGO0SKc8cc97zpqi3ZZ8gSci16GM51SNY0uGDl5PCMfsbekyD 6ED5HBfdVSrCFJj9yUJdIwc+hmSwTnlLYD25xHuQ+nMsvqrngIWOf8KXXhJY6WLp3Rf7 xISAU08GzFUeInvXjNLYBhaEuO9s7L7HXRwej17DSUj1JA1EhTsUs9KBXeG6GPhoK7wY ZNo9fAnXTvLAfhbE1f8vJOIp3JrToC7lw+pc9QnXsANyD1KSd7N6qjlbmmXKDeoE50H3 fpv9DDLx61rUn6g7Iqj2lbDLDdFTcWqV3lc2dj0tEnkQKbh6jBQQub9yHPaoi7nZ3RLU HMwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698131319; x=1698736119; h=content-transfer-encoding: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=SqdvkUsqWd4zu3IEIRbwUNktCPDbd/gk6A5nLT4VIeM=; b=lbDm674XC1Xa23eG72eTfnqPXuhJx3Yikc4zIO8UMUCLAHr5Nvirg1OudYhFGkkRAV l/g4mGG6UFHz4rH0BH1dF0pV/Mj1+AUwMuphit58wTKxoFVQMwVtu8i9bF8hB9LrIoQ5 LHBAyX6FFnrkNlQIJCrfYG5V02sCJ9zVnRjsi7Rcfv7wzZuRdCBbEVu/6sFEMUuzMVsq +0p2ETAasgF9r0eMxsXJIHzw6lD1F2nLM1vNYUbQsVDAswvIB+rcdlnMpa5ey5eFg1MJ S3O9Q0RwgdLMmXPbbBslH3GSVfkl9R5Qz5eKaww2j9RBgVuhansUzN1VG5GdnMpO58za dr4A== X-Gm-Message-State: AOJu0YxDI7FYvVkWxznhkPwG3oelxm4Ea1uaK/YxesG3GRF4p1BaOJVy Y2bOH8pUuYseY2DRDL41VnvwybWIZN5Ga33/3IU= X-Google-Smtp-Source: AGHT+IE3cbJpQKZFd6RGOof+Net59golChwN9iI+4rus52ve4TnU6zTtzWsEuc24BZZmeNAApernLLkRejdVGhlj2/w= X-Received: by 2002:a05:6214:224c:b0:658:7441:ff1b with SMTP id c12-20020a056214224c00b006587441ff1bmr14513785qvc.45.1698131319478; Tue, 24 Oct 2023 00:08:39 -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: Amir Goldstein Date: Tue, 24 Oct 2023 10:08:28 +0300 Message-ID: Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing To: Dave Chinner Cc: Linus Torvalds , 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 , 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" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 5782E180006 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: i8igjcppsk8uaasqx97y3jnwdksgz5ob X-HE-Tag: 1698131320-78422 X-HE-Meta: U2FsdGVkX1+gKHLKWOI1CZfA26O/QZ4+i1s2CmRuErpS3pOIg9JlJP6PLSqeqMKBX0ezqEDcVFCTYsCWy5vIR30geIVUTy43E5Z/sRdL7QVcr9+icgmxB54my/5VUcTYNwOoZvb8yi79ew329b+dKmkhCeTcgYV6+xddfZteME7fhenhIFXDrhivxcnS9WilUNd1UkMLWUTjDlqok3lsENFw/bC6PdKWAvrVwaUra8IxeCYHA2eZlohOdZonUry5lW8rIUz83CVA2Vqi30w5WN08pIEFPBgqPy2p21UCG3KmJmwSdT8N1KdcNtee++21CIUB1tvMDToKY34IPXyS9qmqtNmSUbe743GhPmoTuz/3n0KkBYJig+JlZRoPQ+pASRSEqrfp0DYIZIp+X/S9+/MQIkG7LKNyr1gWt69UF49p0yIckw6yLD/fjWU2fwXLJYfY+K7PQxWfX51f9ho4zKSSAek1evT4pl2FKPGSN03+OvuNZaprWkTSrKAfWf0+5nAhdqWoYpvYVFzKqQ208KdQUuBZlRSnSpBUJU8Qsv2AObk6y+d0XmqeFOOOgPmqerAb1ZlqvGm5te1B/PPV7OhFMivAnSMr6QQsRBKNF0M//w4HIGA3cH3BAGIt7C0MvIuVm3kDnX/n/APUe0nYLvB7CCXDopvn9hu+aW6d06jheaDG7pZegCI+1quZiO5GuoylRwgD9IsOv89fq1m9an+0YlYL7e0V05gzrM4/PhhZMDC8bB6GT0SvjsW/vSxTPbs0MmoQ/isYUHbGLmVh7tK0CQTt2HrBzdndWGTbnuoj2Ox6jQZMUfgxrTlUHDKaAKZP2PZvrrkRXLWiLM+Nk8VBPA+PB345WNKtqS+ido8rCfZKP0zQRR8ij4TFg9bURcUMzkhJhAltz51t6ol2T1R2cZrrbUmcQCDV7DH2IHT8uUoECVOxNKgWkmzgz66kF82yxZqEATmEmMKlEkG FqB1XrGw Z1QzerXnNCXNVYkeumf7Y/Geex38kkh7qxY3JV0bfEI1cyr7xFXKLhCvrdDC+4vLNVwkDQVYYAlKuhNAsO9PKLXvX52TtRzJYLdT3RiUsozwJ04bNE6rNAMNy9vcKooHD7LPaLFpmydhRvqOJVmnsMqjAbC/cV+7VZ0NPaOm7sye/8ZM0SVMmRPJ1XthwhRtH6MDDLWpva1cWPhKdneRa4O4d8a5PaEAkW0/bvmS8YsH00p/VESl+ldpMBeUJXw3d5aZPAo4KI7kKDPRYxmYPiCogV5dr8jAyvkLLsSn44fEcGli+WustlYniEjR7yoPKVaeNd4Am718glSWfWh93Vb452Vp/ZJPXGtnpe28Av2dFMHwrOkAyxofpmm6oriFUbDCFkDm5TVv5wMvjl0jeY4h0EpyojGgtB3Sr 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, Oct 24, 2023 at 6:40=E2=80=AFAM Dave Chinner = wrote: > > On Mon, Oct 23, 2023 at 02:18:12PM -1000, Linus Torvalds wrote: > > 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 =3D 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? > > 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. > > If we push the problematic persistent atime updates to be in-memory > updates only, then the whole problem with i_version goes away.... > > > 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? > > 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.... > 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? 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 distro make that choice. But calling this an "on-disk format change" is a very long stretch. 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 change"= , it is a runtime behavior change, just like lazytime is. Thanks, Amir.