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 DB7E2C25B67 for ; Thu, 26 Oct 2023 05:43:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 504646B0362; Thu, 26 Oct 2023 01:43:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B4646B0363; Thu, 26 Oct 2023 01:43:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 37B026B0364; Thu, 26 Oct 2023 01:43:14 -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 28B106B0362 for ; Thu, 26 Oct 2023 01:43:14 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id EABEC80A99 for ; Thu, 26 Oct 2023 05:43:13 +0000 (UTC) X-FDA: 81386519466.15.5182260 Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) by imf28.hostedemail.com (Postfix) with ESMTP id 35AC3C0004 for ; Thu, 26 Oct 2023 05:43:12 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Gd3qa5E3; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of amir73il@gmail.com designates 209.85.219.47 as permitted sender) smtp.mailfrom=amir73il@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698298992; 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=D0wskKT4pWU48/4FUK3iMC6E9ayAZ0MFNFM/wSMas+E=; b=YRbGm6YDbswbTEcNgCmNyjXo0CI+8K5n6GriHtmFO7naFt4HTLqkhfmamuw6+Z6ksZ8d6w 6BjzHxUHOTxA61OE95EwOCCd3FHldhDdb37NbAkcYh/WluBKM0hu202+/QGAkXuJf1NFd2 chgOYPPXJm0gQ+X2kvRDsur4s9axqzs= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Gd3qa5E3; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of amir73il@gmail.com designates 209.85.219.47 as permitted sender) smtp.mailfrom=amir73il@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698298992; a=rsa-sha256; cv=none; b=OaKKnG0B1+I9CdOUYD2vVWqpdnP4sH+FlJLZDo1IKiHOZMfZfnQZ5e8K99f02gXNXL3Sb7 swc0eWwuXXqNopSwVr+SidrX2gKnNzAudhdaoV2qpxtedxO2ULr384X5DUJpl7qU6kmPiK GBGYG4m+M+eOMw0lRQLj8W1+PY/PSX0= Received: by mail-qv1-f47.google.com with SMTP id 6a1803df08f44-66d0760cd20so4179356d6.0 for ; Wed, 25 Oct 2023 22:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698298991; x=1698903791; 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=D0wskKT4pWU48/4FUK3iMC6E9ayAZ0MFNFM/wSMas+E=; b=Gd3qa5E3CCStBM2CglYe8fOMyK5UyZGo69pwMIgHZCLvdz4wVy+1urppxuWL549jaF GMOAC8K/yTq6gj87a9xSE6m/YIy/thTxImC7sHSvfGls6R7MpQTEsRDHe1xZrxkJvl74 Tw0icQH/0pCwLkTjTncqgocbowrr0/zlqDKqGRcAF5j/P3aYeqKjlMe0MGpw8pD6jqze 6q+TKEAUUps4jQK8TGy2YNTNcT2YrvtpWOkB8eYeRN5FkZf6RjmNG4Kj/rh7Kzx7bIUr N2JSonq/a3eQbKLN0gQzr4VO0dqU1A3DBitaFo7E4OHKGrwdr22JNxj0VnPa78dyz3lk kyww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698298991; x=1698903791; 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=D0wskKT4pWU48/4FUK3iMC6E9ayAZ0MFNFM/wSMas+E=; b=TiCvI5jidLb3ejYNPrGVe485bNkENpXeQzcj17XRViIPu7NsTE9T/vIy6jctoOkFa3 WM5zcR7NZYBDay5TDVrsfME13MKKvr4yzUt4NxCgapw60Jxg2KxXJV0rx50XNMQZovmW rR/v6Qate+kZ1Lz9zXyMmmt8qL+QQEa+aD4Yas1nPY/dWdidbKtYcoik2FrC6IgpIWnB ViPI2VHBJpRBiP+74Xh3DA27522fF7rK51ujanxZoSy2TuJo45HWLTwqgdYI2UHb/MM4 9Nhp+65saOlOarpguTfDQiJWdICdOqKLBL+p2f9op8XaBOYfz+jM9WceJPmhCCXj0PeE 8ZjA== X-Gm-Message-State: AOJu0YynBLwipWqwB5BktmJHSVo9ULqhyWbcK/o8zAmPBNYxEKWmlrtR 064PUKySqGwVDccu8Q8cPCoKZwsxmEC8T0gTpGo= X-Google-Smtp-Source: AGHT+IFtQlJkyk/SemAvlLy18H81rmH3bjGyS6GSbs3XB/X6xHM1ikIcbtxNFkrSUvjSK3z+n/Qk1ZPsdGmCwdu5uo4= X-Received: by 2002:a05:6214:242b:b0:66d:9987:68f9 with SMTP id gy11-20020a056214242b00b0066d998768f9mr2382116qvb.15.1698298991118; Wed, 25 Oct 2023 22:43:11 -0700 (PDT) MIME-Version: 1.0 References: <61b32a4093948ae1ae8603688793f07de764430f.camel@kernel.org> <2ef9ac6180e47bc9cc8edef20648a000367c4ed2.camel@kernel.org> In-Reply-To: From: Amir Goldstein Date: Thu, 26 Oct 2023 08:42:59 +0300 Message-ID: Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing To: Dave Chinner Cc: Jeff Layton , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 35AC3C0004 X-Stat-Signature: qe86be83tr8tf9abe6jwmk1p774cir5m X-HE-Tag: 1698298992-603532 X-HE-Meta: U2FsdGVkX1/2Otc8QlyYAFtG4d/1qRGBIcZGYI6vXc+kl9kx7KXUiMWrhRdHgkVdVcsSUHy+B3YyiUA5jz5YSRFeitmoIiPax0EBckZan02gSFddECguipkPaVdOCkzvQddL1+ibpaKlonr0xisOX3SVwuzX6jI5byQaDRG0ZzwMpblZvj1h2vvbGzQz7vmt0XF7f3e+f6Imc94L2hyPdBS7KrVLRVvTK1oXyE19qppUzyVaWBrGOgYuZ70U+OEEzf5vRDXyCZl9Tukub/nI20eW3vpxcBCab3ercyetcdWIJqUnN0QXv5EHT9/3CYJjQX+30UB8CRVvenLqPX3wRk0DLDZtMoXtRzlOgBpAMScRjXDCZVIZcMaLZMP8Zhl2fKxsXqj6fF82C4Ew6ZEl6T2PYQyv3PJodnCQMg+3K5Y4AUCWIlI2g4jTY7EY3ij7CkqGkCiDRHyjPkiWOEeeF126UOjvYfwb46zsq9Tyr2JwChvfnu2dXZper9hw8TsHgqRlBVrRlAaPFYwdMcJOc+uJabtgzTCtncCKZcGCIqxNOGybfoA+UcnZC2KoGpvF+oQwUsk4F4QHQdyWrpTxx13TuQtTmxmdC6oKA1LnMdqoa3YxTGUio0t/2HeZm9NXGozvV4pFV5Er0NerlLHZdv6D6imsPBZiH7Sg7n3naOGKPWDz1J/77K8vKLF35gz1G9yVwNHiJXz5BkpWJEE+C0+HoY8RTbaoYSTcXwFU/8L23WMU43Jvh1qRFL0N4d/wFSdkShzQd7s3Gn0KXVPsk+rT9JsoTIi4vra8CLg7F7UO+5Q9DJ8CmiTp2GHa7XsGq6IYZEcjyArvBNutsYgFSAyHAKbJw8tpcdJD64WbaRveJ+fZCnrU46mrQCeKtYytdvwXNsboaWn2OFfuZaa2fk9H+ZD7KOZxveuI5Z75ei9ZDnbL2wvH3dN8EMGvulaIR0Y2z0uvDyzUa+YmsYz MT1G9xnT Prrk227U99ddJOFUyolKe04sfeBMtO42UWkq0Ov+aJ2L2iXDA6n4Gh01x7xwpgSieRj8DkCGDaKgZHXyN7BYvFz18Hm0u5tkFHLnQMIkpNaOiy/lw5T1byfAfeGiZklCAFaBdX/rka7uv4U9vU6m0ia59zm1ZOfiR1F6ZyJpyAZ/HLhf86rcWdzF1to6Hsme5beUOtOOeh6ABxPp5WT5WkiHnOpF5jeThyMa3CLx5BVmgKtRmAYFr2r+LJt0izod7dWMRFDYAQQ3k/fi+IoGpGvqWMIK5cYjvbYixQSodE2WvtALWvgkYzZjxetQOUALnr6wR4aXovanB8G3vBRh7jr1b1md9AFOkct8S3P18/5Abe1qzL+CM/01zVmkUQ8TE/UUIbjAWBq923IxE/hYdhsPyes7qfm3+zRS3 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 Thu, Oct 26, 2023 at 5:21=E2=80=AFAM Dave Chinner = wrote: > > On Wed, Oct 25, 2023 at 08:25:35AM -0400, Jeff Layton wrote: > > On Wed, 2023-10-25 at 19:05 +1100, Dave Chinner wrote: > > > On Tue, Oct 24, 2023 at 02:40:06PM -0400, Jeff Layton wrote: > > > > 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: > > > > > > > > > > > > On Mon, Oct 23, 2023 at 02:18:12PM -1000, Linus Torvalds wrote: > > > > > > > On Mon, 23 Oct 2023 at 13:26, Dave Chinner wrote: > > > > > Does xfs_repair guarantee that changes of atime, or any inode cha= nges > > > > > for that matter, update i_version? No, it does not. > > > > > So IMO, "atime does not update i_version" is not an "on-disk form= at change", > > > > > it is a runtime behavior change, just like lazytime is. > > > > > > > > This would certainly be my preference. I don't want to break any > > > > existing users though. > > > > > > That's why I'm trying to get some kind of consensus on what > > > rules and/or atime configurations people are happy for me to break > > > to make it look to users like there's a viable working change > > > attribute being supplied by XFS without needing to change the on > > > disk format. > > > > > > > I agree that the only bone of contention is whether to count atime > > updates against the change attribute. I think we have consensus that al= l > > in-kernel users do _not_ want atime updates counted against the change > > attribute. The only real question is these "legacy" users of > > di_changecount. > > Please stop refering to "legacy users" of di_changecount. Whether > there are users or not is irrelevant - it is defined by the current > on-disk format specification, and as such there may be applications > we do not know about making use of the current behaviour. > > It's like a linux syscall - we can't remove them because there may > be some user we don't know about still using that old syscall. We > simply don't make changes that can potentially break user > applications like that. > > The on disk format is the same - there is software out that we don't > know about that expects a certain behaviour based on the > specification. We don't break the on disk format by making silent > behavioural changes - we require a feature flag to indicate > behaviour has changed so that applications can take appropriate > actions with stuff they don't understand. > > The example for this is the BIGTIME timestamp format change. The on > disk inode structure is physically unchanged, but the contents of > the timestamp fields are encoded very differently. Sure, the older > kernels can read the timestamp data without any sort of problem > occurring, except for the fact the timestamps now appear to be > completely corrupted. > > Changing the meaning of ithe contents of di_changecount is no > different. It might look OK and nothing crashes, but nothing can be > inferred from the value in the field because we don't know how it > has been modified. > I don't agree that this change is the same as BIGTIME change, but it is a good queue to ask: BIGTIME has an on-disk feature bit in super block that can be set on an existing filesystem (and not cleared?). BIGTIME also has an on-disk inode flag to specify the format in which a specific inode timestampts are stored. If we were to change the xfs on-disk to change the *meaning* (not the format that the counter is stored) of di_changecount, would the feature flag need be RO_COMPAT? Would this require a per-inode on-disk flag that declares the meaning of di_changecount on that specific inode? Neither of those changes is going to be very hard to do btw. Following the footsteps of the BIGTIME conversion, but without the need for an actual format convertors. Thanks, Amir.