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 51BCFC4332F for ; Tue, 31 Oct 2023 23:12:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CD98D8D0012; Tue, 31 Oct 2023 19:12:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C63018D0003; Tue, 31 Oct 2023 19:12:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B2A9F8D0012; Tue, 31 Oct 2023 19:12:58 -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 9F5918D0003 for ; Tue, 31 Oct 2023 19:12:58 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 80BFD1A0BFB for ; Tue, 31 Oct 2023 23:12:58 +0000 (UTC) X-FDA: 81407308836.22.77726EE Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf10.hostedemail.com (Postfix) with ESMTP id 1A3D1C001A for ; Tue, 31 Oct 2023 23:12:55 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UWVsN5tO; spf=pass (imf10.hostedemail.com: domain of djwong@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=djwong@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=1698793976; 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=wFjx91/pyqJxwgCSmV4WIY8X9mvFP35ksAITl4fuEEs=; b=non2VCFu/fcWtD4GOrJ1rDVymey8aLBp/6cMAKjQ10TkzFEbmpY3bN6deinrY872s0YD60 KVchpxn3bNvxypEISEUMxF/g9m55/CwsI2FMTq3djhpfoluy0WHpMVgwu5Zk8ITMIHcshT yv/02Uepk2/Ji/BsdsMxIySwXKzMYrY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698793976; a=rsa-sha256; cv=none; b=61s210t5LwAhqOzl/UVCEc1/gj6RMt/L1XG8x8p03soqQAPaTRjJfWslIKQWvif5cZK1jK E8hAWkHLN05JzzZ2Stb0jw99ilV+3gg0HfxYDIe30Cdmc3N/wBfQvGuV+USpstUjSC4yel S/p7ovqxkPzEXKJpMBBYHphBDXtPZ7k= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UWVsN5tO; spf=pass (imf10.hostedemail.com: domain of djwong@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 5E6F5CE0E77; Tue, 31 Oct 2023 23:12:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F876C433C7; Tue, 31 Oct 2023 23:12:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698793971; bh=HUHN15gYL1zUQAZ/9kbQyYuReBV1adG4NcrFQI5O1EA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UWVsN5tO54rx3f5rm/2Q31gDwhbSjKfQC6V5qBLtEVr4Rwpj7I7yMkvepTMR/lTtT VZqTAW/Ni44oDy4DxIjDO6jVJnB3XhJ1iXh/jS/mwEM6mkBwXfzeYhmhhzk0O3GH1C FpD5ET6CpsJs564xQRPuK4enmdSn0K5L9FR73kX/HjPNJDmk0zU7wpeb5rhu5lYajK tqce7Z3t64Zk3H+3LHPpkEK22xLM57Jc8HFHfmu9721nBL0Xsq/svRRP9VsvB3XdNt WDyDN0dl8KXCOPtrduLbhpDz2EwAI3OEgEsUZRP0GYvAfodXBg89A0KEIH+Eygdi1J T4yRHuxrW0+lQ== Date: Tue, 31 Oct 2023 16:12:50 -0700 From: "Darrick J. Wong" To: Amir Goldstein 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 Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing Message-ID: <20231031231250.GA1205221@frogsfrogsfrogs> 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: 1A3D1C001A X-Rspam-User: X-Stat-Signature: c8igyahnwpbr37qb5c1itshx5nc6you8 X-Rspamd-Server: rspam03 X-HE-Tag: 1698793975-535532 X-HE-Meta: U2FsdGVkX1+kokjWBa8iITuPpCjtMk8N39QTXek3/EEUO0A3x+vAlY5frajr0YI5J0MWUDau/bIoqeUTIAsODn43j8W1uO6iajJI6J1fH3k7Lvnc/ujxrrZ8D23ZEg0/jdeu6RPvzQ5EZEWJdiE5GC/RjMgp5Fm8DmliRCXyMwKJw1f3r2Hh7YnPvGzFQqxC8meWGz0lwmZwsHiEjKLT3zQXpEwNy7NXXeXKj9jDTV7/rGaGGQz+8kECTexhmguxx1ntpSvNiYsj2y5I4sYbLgfIyS4xUksZaDu7R5VPG0In5KhE52Po+R2rAroR91OSpL+TkGTwx5fKOR2bU4seh99UWf/aKOXzpVi1JkOqDOL8pgXCYaxxE+DHidlTE/nNvPsaXfixPzU4AK+J6a1w5Vyb3gC1ObbrLmEu6qvI97syH69YWdoCYtOpiUXMPhAe7tE5hAdjdftR/QIFilz5Ws02VuScrkuReZlA1bpQwr4B4etmmPUBW64swW3CRIo2guN5ieGeG6gL5njVEgKqM8QN9miU75dVA3aF/6vAf0ZhlyeRdQ/5SUOv4qK7E00SXqK0u42LqbiZhD+PZZfYjyzuJnZmolHY2OqylSq4aCuh+hXaWABhKr8rInczPyjN4ASOEQAYnqhT7oAggLZH1h/j7bQG8a/f7gRqgUySCalrq8x8GjyT292zYwt91vLSsJaKO5BLN6SKqkgozLyIFXYZjKOzvnJMcGSc834PIpOw3Oa85jLODdmXdrDfPYL2KQO4o46PfYNcAUxYCOTss8XiGRBGNOtA++su8NKmuC6K0XAGh5cyi44Gy7Lt5UVn7fgAf/w4LiJyl1e29tNflYtITsJCiwM9uxSQdrMVhZcGfj6q7wFozdXB4X0FGCz/LD7/Wl4PVCOc09OjiAqNW0osiMQolrCFDFOMjMJvM93c/xVERMS6NiW6eMSuMUEnJ8qiXNdSON5RIrG3I43 1XAGShJh H2y5Yc+Nf5/zysgqG8nVV6mGjh244mu+tTQQ95wwWiPd6eP/vjeyx41Lj/7FYN38SN746mQk77rKp523tZmhsXwv6uuMU3DeYDC8o/0JRyCJjBgF5mRkZyw+StwnDhuUqGXm+GioN7U9WD64JpFIlDQo17KEtkwqW8zsLfncwPSHKidtyWE0B3T+EwmlxWx0lyYsrWYyBB8IS7ZvJF1sBeRNNXkCkicqxPvp5hSjTd9rmGIYQpcstt9hMu3KFoK+jIbLIjZyzssmCb7M= 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. 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. > 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. Kudos, I cannot figure out a non-pejorative word that rhymes with "**API". ;) --D > 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. > > Thanks, > Amir. > > [1] https://github.com/amir73il/fsnotify-utils/wiki/Hierarchical-Storage-Management-API >