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 CB2EDC4332F for ; Tue, 31 Oct 2023 11:29:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A37B6B02E3; Tue, 31 Oct 2023 07:29:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3537D6B02E4; Tue, 31 Oct 2023 07:29:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 21BC96B02E6; Tue, 31 Oct 2023 07:29:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 12D016B02E3 for ; Tue, 31 Oct 2023 07:29:28 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D3EFF1CB519 for ; Tue, 31 Oct 2023 11:29:27 +0000 (UTC) X-FDA: 81405535974.26.3C541EC Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf21.hostedemail.com (Postfix) with ESMTP id 7C10F1C000B for ; Tue, 31 Oct 2023 11:29:25 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=szcK99jQ; spf=pass (imf21.hostedemail.com: domain of jlayton@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=jlayton@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698751766; a=rsa-sha256; cv=none; b=iXSpLjpLhifq99Z2kMJYg4k6uNpyx4WcxY/405ryJ3QMMC5K6m2lHAEtkmX3zNB9tNXM2b gilzYiSHzUJGJq3fQWQn7U64j8BYxo6F3w5jFM5P1oPPtJEco+APaP+YGqVV0/8qWwXPhY ue2/YmBndBAl8+pe6hblwQl5SbyBpao= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=szcK99jQ; spf=pass (imf21.hostedemail.com: domain of jlayton@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=jlayton@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698751766; 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=fz3Kt6Eszm2Wav2Z48k0LnmutspePZBudBSBfqy6NRo=; b=00L0mWeZsvql7fROWkbI75IjT4Q55VsxVrlkV68wv8zWApo/IU8hAzXuiKkbSYhPLnhGUl jZU3yNB03fdoyvoxcD0kvBAQG2gdP1yZ9U9iXujMA+veLbGURQpKhjGN0ov22HGAxD17ip wOPjiySpL0r+HGK/1QvpafYGqwLVRhQ= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id BE07BCE0A39; Tue, 31 Oct 2023 11:29:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AAC34C433C7; Tue, 31 Oct 2023 11:29:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698751762; bh=sQi8lLN99TqACM6Lr/LTk68QS9WcLZ1H4O7ExjoVBrM=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=szcK99jQWDGhlXMi1UgH+Os3Ra+DjckTFa7eXi2kTman6U6wMaiPqiHE0ZUb7/2zU SxHagS2QXuXkot3N6SG26/AfQjhmkK3OTBneaxECmrkBwHlxt4tEEd2b5Vf4DVWEty +Gy4OK9zIxQsh7X9k178PrZDUB2B3ULtpSkR3p0AgVJPSURjL40mlCwxjTK1hAHwQV JCnIuZYdexIZDob5OIE0bV5CWZy/m8dHmIeGwvdmPApv4vcsah3tV52UAUfYKAR5Us 3of6oyBVaM+ko1bQu3KUaH+BILSplQUKX9RZpAnhyNe+62km1wfnW/C2jHnZmRv1AT crFIyLnj00vXg== Message-ID: <3d6a4c21626e6bbb86761a6d39e0fafaf30a4a4d.camel@kernel.org> Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing From: Jeff Layton To: Amir Goldstein , Dave Chinner Cc: 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 Date: Tue, 31 Oct 2023 07:29:18 -0400 In-Reply-To: References: <2ef9ac6180e47bc9cc8edef20648a000367c4ed2.camel@kernel.org> <6df5ea54463526a3d898ed2bd8a005166caa9381.camel@kernel.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 7C10F1C000B X-Stat-Signature: bxdrfea7hr6p9pgp8g74dpun8o7j6wz1 X-Rspam-User: X-HE-Tag: 1698751765-468839 X-HE-Meta: U2FsdGVkX1+oYUhKX/Rxn2LPl4oRocHaDWb3MMTKusn1PCgewnvy1H4vG+dFGkgheHr53j6Ot+3IyX+g560+aEhMg1g6/or458s5jWBiDifJ0TjwqyIYUIVy1ZEC6+Y1OWaCea88ZuZpZqiq7zR42xJiN019ebUuNrhjuFRTJwurVSA1xNY/qpE8lkid9odzFT6cxY3XgtZAISfusSbxpp8Tgrateg1mo/SKqbb3c2Ttv8PfJIgZ6wuJX59Exz9DJxsFY3T0mv2llp0ZV8N31dtwihPafCPtsFcgVrFo5LMt/lj64aZFmcff4C+oOef9DR+MM1I/CMvhmR3UeWVliLySILdSvzs9QWBVZPdLyysYiIrbN2nC/NafMNk/Ecw+3C71Wp9FGOOq3jOWz89xHJY3Qs2RqWbVC5jCs6QTtlTsvB8//AXoF6Yk9m54tiw/3BElNoS286AyWzKlZYpH1oP8+gm1AwRFrZ70i8KNzMdLUkEhuB75V6XTye3j4fJZwXLPnQSMSSTfGtulFtESBGqb1uss2eKNL1Rx6QfDxiXy+eQcbdsTcmORZN5qncyfpNbdBSVIC0U36S8s4KhfFMxUxfxA25v+Yd8UsYV3G3BzGxXUlLI4CKe3eutEmNQ8pgqKcwUx9zY8PRulEoK2hf1QgUHLy2Yjd9TLTbITHhCn/BxIhSwIwnlmu48blm+Y3efL5VKIqUmtKERQsLXfjFqP9VGMbD72h5/WKUmM4l1uMvw2YFdYuY2ADbtsPcqvhV2NeIYe63DhkK8Ok5mhBxeXY5iF6TQM04uXlfyaUUy4v5dtEvRF5TWhD4jY13dcsxcjydOQ0WDRqrNPnpXtg0fYz7p1tXBjMqNdxBxBo7wGejHxTes+WLcFNcF46/zAi9rO8pYb05ri6tjQxXgAjvxVGBq5pOANNo0uBeXtN7uHjc3lKzybK8VEldj36tsbZX05Fp6BgDSXwV3PsyW vpKNzPzj lbJwydoIyvIJB+ZKsKrvdAilDl6w39BYvwEEwQtUIvx+kPMSKuuGLYT6SqfTmQwXtcCMvJ/8TMVbyutkYeYSBj3mpWXAlp8xtB2E7HatUHBzsR9yd4QP1BFGA7l3Ihh1g5XlpRn3gqw2BIv6wLF8/eBtLoLXIdhIm9/p8jr+958PUn6ZppHFPfeNaFwA+JduyewAlKK3BckjW/LwPwurtRwuOkeOwoNozLXdDiq/SS1yBG+gzcN1+auO7eq9KXAItod4neTd3ro6P/uk774u1MhdfLRZKIRTSWLQLY09AIJbz+fQKPrfoCQTpYaiiBB35nHx82aO82+CBaio= 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, 2023-10-31 at 09:03 +0200, Amir Goldstein wrote: > On Tue, Oct 31, 2023 at 3:42=E2=80=AFAM Dave Chinner wrote: > >=20 > [...] > > .... 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. > >=20 > > 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. > >=20 > > > 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 needs > > > to update whenever a (persistent) atime update happens. > >=20 > > Yet I don't want i_version to track di_changecount. > >=20 > > I want to *stop supporting i_version altogether* in XFS. > >=20 > > I want i_version as filesystem internal metadata to die completely. > >=20 > > 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. > >=20 > > 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*. > >=20 > > 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.... > >=20 >=20 > 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 adaptations > also to mtime. >=20 > 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). >=20 > 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. >=20 > 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. >=20 > This feature is going to be useful for the vfs HSM implementation [1] > that I am working on and it actually rhymes with the XFS DMAPI > patches that were never fully merged upstream. >=20 > Speaking on behalf of my employer, we would love to see the data > modification-cookie feature implemented, whether in vfs or in xfs. >=20 > *IF* the result on this thread is that the chosen solution is > ctime-with-change-counter in XFS > *AND* if there is agreement among XFS developers to extend it with > an opt-in mkfs/mount option to 100ns-mtime-with-change-counter in XFS > *THEN* I think I will be able to allocate resources to drive this xfs wor= k. >=20 > Thanks, > Amir. >=20 > [1] https://github.com/amir73il/fsnotify-utils/wiki/Hierarchical-Storage-= Management-API I agree with Christian that if you can do this inside of XFS altogether, then that's a preferable solution. I don't quite understand how ctime- with-change-counter is intended to work however, so I'll have to reserve judgement there. --=20 Jeff Layton