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 7BD6EC4332F for ; Tue, 31 Oct 2023 10:30:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1EF466B02D0; Tue, 31 Oct 2023 06:30:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 179006B02D1; Tue, 31 Oct 2023 06:30:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0413B6B02D2; Tue, 31 Oct 2023 06:30:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E3EB86B02D0 for ; Tue, 31 Oct 2023 06:30:38 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B6D6A1A0B84 for ; Tue, 31 Oct 2023 10:30:38 +0000 (UTC) X-FDA: 81405387756.04.66EE895 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id B763C40019 for ; Tue, 31 Oct 2023 10:30:36 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Ev4ne27U; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698748236; 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=fwuBnNg6GhaGnuCPEKnkXJZ00BGnt4w8Z0iZO33z7Cc=; b=gN20lEp+KFGciSUKFPAHPpA6bHNzdquTpk9+gm0uLZuVXM569OweD9IStq07RADiqJoc4S 2vuZu+I/6cGQZ5RK04NteyC5SsA8x9Rcbbqw7WQauL2zrDVrx/8KyPBsGg9AL5A6U+xFNQ LcZ8Fw2Gb8gKyH51rmy7zhzY6yfnb8s= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Ev4ne27U; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698748236; a=rsa-sha256; cv=none; b=sYUS6e0sPZy8iD9XN9yLtEwR3w2+KKLT3xlIMd14Q3+FAkJrnP/H65rYx9oOFF1FjtoWsk t/Ck5W98cPscUdUxBSdko7Y5dYFSomgtlAO5dDyBRUAOQiacVvcraRHCNaxuRRFzyTQoCd j1fMDTEJcVMBi4iDxEXM0ozz8s6PWdE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id DFA2F60E83; Tue, 31 Oct 2023 10:30:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 90139C433C7; Tue, 31 Oct 2023 10:30:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698748235; bh=qK3DGIVN30CKCk3p1WZsI6EB6xDHe02lYO5vyQjhTno=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Ev4ne27UuOjVqfb069C6Kp8q4wAkmqKcHOZnhZaz5Lffycjx2yIUBuXCcCDsZ3siX G6uZQ1wsxRqji+Ao4acLNfn7DtHmozcJ0m7EO8jW5X/YYhq22IFP39o7dmX++eG8GZ IZwju4kgUE3lclL0INhItoadbL3vBe4mee/EtII7AqeLfU5XHjH0nOWc0QYeshRPcF FGChyjaNxpd0vtlynXUqoMiMbw8j9kPCxNzUPey3vCutJlX2MPWSiD4TdqWdGGL/iw gK6TpA/2/Xvo0xlstAK5oDPQpbyVNuK44iuuzwyWOkwPH25mCgGfBluTv4lRxgt4gO /MmCASuSt/BVQ== Date: Tue, 31 Oct 2023 11:30:21 +0100 From: Christian Brauner To: Amir Goldstein Cc: Dave Chinner , Linus Torvalds , Jeff Layton , Kent Overstreet , 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 Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing Message-ID: <20231031-jobverlust-auberginen-04f47d380f59@brauner> References: <2ef9ac6180e47bc9cc8edef20648a000367c4ed2.camel@kernel.org> <6df5ea54463526a3d898ed2bd8a005166caa9381.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: B763C40019 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: yz8pcgdtf9th7tssjgai6mr3b8sg3f7n X-HE-Tag: 1698748236-305957 X-HE-Meta: U2FsdGVkX19+wMScg4d1xJWvD69TKNvSTB4XyDzspBxfr3WInxox5lij4xxA1VoN3caduDR4KS7kJWgwiHLGkBuJIfb0D+ZFyQYT5bPFw7Eoot7JMt7cqOSq2EWeys3vNwSwXpC/X9tWyrSJIOLF7q6Bo5QTZOdDxWXEbpf8XiFw8fCZGDVdagMn7ajq/fb/Gg2aH0xIqOJ++NgcamTtSIucFYTNP5vnnL8kXPD9XItEbwPGHy/24u02GbgTLjwRq8tlWvz2Gs8G1GrQD2yT0U4TuwtssrX4o24UJg0QsP8CNrWF5O+bcb4IuLrO2Dq28sG0jbr+FIdmuCcrxWn/o3RlK20fh79ONnGNENF7dLfHyDpcVVo0vNnZCyGBF+mn+JrRFjV0+CwmUy7nfCEuksuPX7Zng5xPSTAPqAUnZsJIVKv7di7LxF/s3tfnrZNLVEGHXieSv4rYXQPkuWpYMqoDBP01LZ8ErIPjz2L1tX0XcFqjYaXvq9MPPmea73TvXjPp69QRujoUxeBh+lYpld1srrlxZPBdpvWLE3H0QhDujza80AKwWKwLjzbpuUz+vNGsZqqc/JkQKnFf+AzQjMP4Q4GSqY017doztSwdQYaBf3MS15BIrtVwG4rNrGAMTtXM/zRCNLjgHurMdS10GhCI821cqshFAtuGewNxu/l6raSojMZvslEyCtkcG5CrXLYYb5ecJENU8QK+WdSOGJjwbZ8aIcxgyMX/cRo5wBDbAeSQqPlf27lHCK541Cpv87lu0yF45jxcGSJOTHQG0OX8BQaVn/t1aql3bTFZp2viG2WGlrcWwleaqI2HT6WuOkMSAZtokScnrotdxs1uiqmoz9q6oiivw7R0V0IAK8fyGMxalYGOA4yKQjJsEJtpEIzhl6cTGbDiEM+2bY+UFhxS5lA6asbNZib707qaEv6wyjvWHwRmo/RxYIRnKPYN4mG46dbh8xkYNQ7umfW smClnHyn OsCPqV1bVYWRm2WrdCtxfXvEoOK/nzeNPCBi0rIqUY93SRzGI/3gj5WHWsKYvDwa1fFpvFSRP9mhub4jjKaXHUSc1Rn6yM6PXnTpZS47uYgV/HdsHHYi3nbwQFk+4GTRK4L+Ei787AmETp1ERsuCvKb1DNhZm6ynEqtnZrSgFpE4M+usLfMJljfU7+Q4Q0FwEm88tKZ0EwlkvbQVc1M0OWyq873hpVtmf3kHhxxzx6w1cJWJgqXB71aQygw== 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 31, 2023 at 09:03:57AM +0200, Amir Goldstein wrote: > On Tue, Oct 31, 2023 at 3:42 AM 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 needs > > > 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 adaptations > 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. > > 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. > > Speaking on behalf of my employer, we would love to see the data > modification-cookie feature implemented, whether in vfs or in xfs. > > *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 work. If it can be solved within XFS then this would be preferable.