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 28414C4332F for ; Wed, 1 Nov 2023 08:08:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 67BB56B015E; Wed, 1 Nov 2023 04:08:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 62D676B015F; Wed, 1 Nov 2023 04:08:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A6466B0161; Wed, 1 Nov 2023 04:08:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 34D3F6B015E for ; Wed, 1 Nov 2023 04:08:52 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 02289120B3E for ; Wed, 1 Nov 2023 08:08:51 +0000 (UTC) X-FDA: 81408659304.01.E7B2B6A Received: from mail-yw1-f179.google.com (mail-yw1-f179.google.com [209.85.128.179]) by imf28.hostedemail.com (Postfix) with ESMTP id 49114C0019 for ; Wed, 1 Nov 2023 08:08:50 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kCH3qz7m; spf=pass (imf28.hostedemail.com: domain of amir73il@gmail.com designates 209.85.128.179 as permitted sender) smtp.mailfrom=amir73il@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698826130; a=rsa-sha256; cv=none; b=uK42Ho4TYaa6yplnmxkV0qNvN0wVQ4YS9ULxav8fN99gonJp5TrLpHLJX86lk4TaPcLPr/ Gl8ESohnP0+18tjfAnB5xjCzQ+YQBca2KkQp9Xe0AeA56fyMsgGiF7wRuN7gWFUAcj382Z WtJbCG8Kc3eRywnNAJr9ku0WmunkTus= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kCH3qz7m; spf=pass (imf28.hostedemail.com: domain of amir73il@gmail.com designates 209.85.128.179 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=1698826130; 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=zgfbgSEobRatousrajtd1MKUo9GGvoyPH04y8/doDqo=; b=DTSF3g5zweXPy1dbCLOpKXIQRKRaCIiQAo2bUCACnRelV/UE2Jbr/ZW4o/MIZs65gx2UdL 4fQ97YLbG+4GbERB6GkxkYVBtLkWHMgDM7JDnIMxJpJQq5DzCgae61SIWWjser9o6Rz7pX sdMKEKZhGvIM9o9molKgZ3YCt4JtBFc= Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-5a86b6391e9so65099387b3.0 for ; Wed, 01 Nov 2023 01:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698826129; x=1699430929; 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=zgfbgSEobRatousrajtd1MKUo9GGvoyPH04y8/doDqo=; b=kCH3qz7m1C87QLe4paiphZJ0ne8ieeCroLaI9ZMD/rhlHORvlLMtpyGJlhULIIarL+ vtS5GbTzD5l3cTMOks0or7e8RlAXf/lbjns2BwHLkcdckcg9gmBfD3Yo4y8EShTnRte2 6Ou02dwlyvxMfkY+hNco5bjbpc2CIydyNdZCMZG5RiNwYU6x48ATuINMvBV/2UEc+y3v gbhIeRj/4qMYIAy/jx2uQFlQ0bN+IwSaeJ0AcP8lC05U022xHuxzQoafWIH+oUeBdENZ 8o1/vLo61xCpQS0gHDJ/LQ8LJV5sb2YlYdSOdNRDsg9QGP6/Eh+lZAz3+4z9iLGNXIOe w4sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698826129; x=1699430929; 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=zgfbgSEobRatousrajtd1MKUo9GGvoyPH04y8/doDqo=; b=KipBFsyeOo407D4zf86fY3HBZ2K1F99xGkFhsgy90pFQJjFiJsMjrSlduSquoKHhs8 PNNWPTRShLNsPDggpy2uORvXZL293GzeXkucZPIEhQL1sqdLNhjHR7VYo4hA0KWPwVyU HOMzBS6HLAjrJ2n7CVnP7xYXGzAlCAE3j5WZo1miAifBKjp8AqBwXYIm4d+DofKkeYLG Ln8MVeKVGEE77CeRzYi+MfJeLMPL1EmEFd0Y8c3d/Swt8fGg0CgEbq3AfSKV2E9sN/TB psB/eTrV08TBIcipkywKiFkhUdSIRP6mDu1X6jyHcw+efVKXBpGC8hiTcarna/TTzNUN UvWQ== X-Gm-Message-State: AOJu0YyxC7XCHEPRFU2sxob0OFTmvYn67HSQRzF7SatUC21pPOMRHywU QM4I6JmC1igRxZ4aKY2Jb0V1bCH/6E2htpnxLJw= X-Google-Smtp-Source: AGHT+IGRBUWRysQM9zIevnqz2kXSdSgC1kLwK+R6pM3Ky1i1gtJgobEMFWL1l8JxKMDWCm+cTvXeqLv8Z+MqOa/srO4= X-Received: by 2002:a81:4109:0:b0:5a7:aa16:6b05 with SMTP id o9-20020a814109000000b005a7aa166b05mr13757515ywa.33.1698826129298; Wed, 01 Nov 2023 01:08:49 -0700 (PDT) MIME-Version: 1.0 References: <2ef9ac6180e47bc9cc8edef20648a000367c4ed2.camel@kernel.org> <6df5ea54463526a3d898ed2bd8a005166caa9381.camel@kernel.org> <20231031231250.GA1205221@frogsfrogsfrogs> In-Reply-To: <20231031231250.GA1205221@frogsfrogsfrogs> From: Amir Goldstein Date: Wed, 1 Nov 2023 10:08:37 +0200 Message-ID: Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing To: "Darrick J. Wong" Cc: Dave Chinner , Linus Torvalds , Jeff Layton , Kent Overstreet , Christian Brauner , Alexander Viro , John Stultz , Thomas Gleixner , Stephen Boyd , Chandan Babu R , "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-Server: rspam08 X-Rspamd-Queue-Id: 49114C0019 X-Stat-Signature: pgwe8x65eprti8otgqwojja7ngtnpncs X-Rspam-User: X-HE-Tag: 1698826130-799691 X-HE-Meta: U2FsdGVkX1+ZB8l2oKaScgjvNtWebpX7XypsIKI1xTknpAwo+96AaI5nUhQkASIx1wZLSQ2u/O46F8rzJ2+D377Fb7vcSEhnrWhphV/iEZ9UQaGgIFtHBBNf22bSx9b3O0sa+ZKoqyWvSF6DyH7xkJGy9fsdLfQ5PMWFA5+2HQB5JsczxnvfKhu8yb6ijPujYzylZ067h+NUQ2PAd0caEbXr+Ok8aijYVa0dHm5ksr575xgtOan2T6NJfdikjDqEH6mifZZxfuhqAHVDqQqsKeLi3BI7jdQTx29xeTq71KvdSHxR8cGaCHJwOCc8/fNhV1ioWDyI8s/L0qqzbpRKhpPH2OfH9akhCrnXjzkxtzDBPUV71NBqHoKvXPO1VRwPbqJfpbNxivhrLbFes3bHZJ6EXb0+NpY+KwriXFbcLzDO+uy5h8+KMC6yJKlzrCMrX4BS3P9tLg9/ay1HUuZc+cIh6r4TSOnA3oHrXt1RzLeKh2BlZHvooDFIpGok9b/9XwqR01gMc9vjqYlVt8/JZhC8NwbfSwadX/MguBpBCCD62iwN0X+CvrYhOwjyTmmysCu7ncu0dY6DFYQBddNps1ZYayok+S5yeY7fCI1zCz7DtTFQu+lY02h1Ds5qcFUsIRuwcGCYeU9Drz1bpnrxEapmO+EHoV+5MnqyLMbg7ZtFMRdMnMDsfnQdZoiHNEihg8ps0r9MIMIkN2tfpeS7Ey99ryI7avFggv25t/Ypqf6A3WD7Es9RCbpxOijjf2TD1JQjqziwJh6qiEypsoU9y6jxWAsc67Kj6dlr5NkSdBp1nEjpI9HGw3dhf1D+5g34AdrND69qFcQpEjT3j7IsHtOigatcYh8uBonGYfXNzglPtVNPV0pK6AEajzUvQxTI6Sxz1NyOmF6MWW8rChrNufaG/DkyF1/072Vjd7eqtkj7jalRBz+T2jrziIWYmUM4ReglNUDAQRFZsxPI69x 395BP3+D q5QuYq2SRmBy68jPyUFQgzUS+O/qt5/Ut3RofLPlPVrymQGNqwbF47SP/ZAVnu6XK/F7Nqf2rYlVCisqu3sR449m7AKh0qjil2qj5tYw6eko6bZIBDZOENLezCOmDhhLM55cyUaIQGB9CuMqELV87nMDrAIm4uTU8wrTKxbWQbQCpYMtNw1J0AFlYAu2zbW+3ip3fL2QwSAWxTblYTaveAugPJO8YhrquS5L4jgtQ07mOaGStWJBE5lKlrAqz9gSfBkach6TOPr6JynOfsTRURER7L0FPzujOx5TQDJTvGGBwB78BLwdt/TPP1+7dO5CjMqYSWqNC7HslLhBT4MWfF2/Ib5P4HF0dJSODXvz8gqu38VjYxnB/x5El09CwqDAdS2/jDaStDMSJs+jLUDqha93YnTuLVcKNOHGj6fAYUGoLz7nDTZ3k/UIaq3aT5wQszMBtcHiTTTLGET7l4nw9BttDoTQVwF3/Y6vx 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 Wed, Nov 1, 2023 at 1:12=E2=80=AFAM Darrick J. Wong = wrote: > > On Tue, Oct 31, 2023 at 09:03:57AM +0200, Amir Goldstein wrote: > > On Tue, Oct 31, 2023 at 3:42=E2=80=AFAM Dave Chinner wrote: > > > > > [...] > > > .... and what is annoying is that that the new i_version just a > > > glorified ctime change counter. What we should be fixing is ctime - > > > integrating this change counting into ctime would allow us to make > > > i_version go away entirely. i.e. We don't need a persistent ctime > > > change counter if the ctime has sufficient resolution or persistent > > > encoding that it does not need an external persistent change > > > counter. > > > > > > That was reasoning behind the multi-grain timestamps. While the mgts > > > implementation was flawed, the reasoning behind it certainly isn't. > > > We should be trying to get rid of i_version by integrating it into > > > ctime updates, not arguing how atime vs i_version should work. > > > > > > > So I don't think the issue here is "i_version" per se. I think in a > > > > vacuum, the best option of i_version is pretty obvious. But if you > > > > want i_version to track di_changecount, *then* you end up with that > > > > situation where the persistence of atime matters, and i_version nee= ds > > > > to update whenever a (persistent) atime update happens. > > > > > > Yet I don't want i_version to track di_changecount. > > > > > > I want to *stop supporting i_version altogether* in XFS. > > > > > > I want i_version as filesystem internal metadata to die completely. > > > > > > I don't want to change the on disk format to add a new i_version > > > field because we'll be straight back in this same siutation when the > > > next i_version bug is found and semantics get changed yet again. > > > > > > Hence if we can encode the necessary change attributes into ctime, > > > we can drop VFS i_version support altogether. Then the "atime bumps > > > i_version" problem also goes away because then we *don't use > > > i_version*. > > > > > > But if we can't get the VFS to do this with ctime, at least we have > > > the abstractions available to us (i.e. timestamp granularity and > > > statx change cookie) to allow XFS to implement this sort of > > > ctime-with-integrated-change-counter internally to the filesystem > > > and be able to drop i_version support.... > > > > > > > I don't know if it was mentioned before in one of the many threads, > > but there is another benefit of ctime-with-integrated-change-counter > > approach - it is the ability to extend the solution with some adaptatio= ns > > also to mtime. > > > > The "change cookie" is used to know if inode metadata cache should > > be invalidated and mtime is often used to know if data cache should > > be invalidated, or if data comparison could be skipped (e.g. rsync). > > > > The difference is that mtime can be set by user, so using lower nsec > > bits for modification counter would require to truncate the user set > > time granularity to 100ns - that is probably acceptable, but only as > > an opt-in behavior. > > > > The special value 0 for mtime-change-counter could be reserved for > > mtime that was set by the user or for upgrade of existing inode, > > where 0 counter means that mtime cannot be trusted as an accurate > > data modification-cookie. > > What about write faults on an mmap region? The first ro->rw transition > results in an mtime update, but not again until the page gets cleaned. > That problem is out of scope. As is the issue of whether mtime is updated before or after the data modification. For all practical matter, HSM (or any backup/sync software) could fsync data of file before testing its mtime. I am working on an additional mechanism (sb_start_write_srcu) which HSM can use to close the rest of the possible TOCTOU races. The problem that modification-cookie needs to solve is the coarse grained mtime timestamp, very much like change-cookie for ctime and additionally it needs to solve the problem that HSM needs to know if the mtime timestamp was generated by the filesystem or set by the user. Thanks, Amir.