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 EE909C4708E for ; Tue, 31 Oct 2023 13:55:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 62CFE6B02F9; Tue, 31 Oct 2023 09:55:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DCFC6B02FA; Tue, 31 Oct 2023 09:55:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4CB876B02FB; Tue, 31 Oct 2023 09:55:16 -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 3CEF46B02F9 for ; Tue, 31 Oct 2023 09:55:16 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 09D0A80229 for ; Tue, 31 Oct 2023 13:55:16 +0000 (UTC) X-FDA: 81405903432.06.BD2766C Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf10.hostedemail.com (Postfix) with ESMTP id 3CD52C0016 for ; Tue, 31 Oct 2023 13:55:14 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=BlTYxX8b; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf10.hostedemail.com: domain of jlayton@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jlayton@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698760514; 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=qIx7b2aoxjsw7TSGPFkMkmmuPqzNI4IGu1YwuirwcKE=; b=voB0yHkWrNydn0L1lvpu58nlCUyZqw8+TUxbrKJLPml9KCMU2FB59TVxyD1teedpYlXv5f w2HAhYMMhwS7pnPUNhMXkYA7ApbnBT8jWhxXpHWDaIOtb2RaXduFvbR9YN68pSomD9Gpno q82WOayL09ehJzvF+lqnnx6PXbYsvDc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=BlTYxX8b; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf10.hostedemail.com: domain of jlayton@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jlayton@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698760514; a=rsa-sha256; cv=none; b=IQssijbjbeMukhN/qdL95hMUWwp9aEjkB5D2pb8rGWi2mkFDUw04C8oUdV3yO9bkFfthlZ ecQ6nMZ3FFhrJS+viADT4SGriy5mBHeyUGc+2qoPqE3zCjZ1gCEHUDRRNXKkXT6CaKmOS4 rF18FFcOVIdi6dOKOY7MfTCIJHBB4jE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 15E5F60F23; Tue, 31 Oct 2023 13:55:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 927C6C433C8; Tue, 31 Oct 2023 13:55:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698760512; bh=qIx7b2aoxjsw7TSGPFkMkmmuPqzNI4IGu1YwuirwcKE=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=BlTYxX8bg/TyNm9k1G7hqu+6cgvScqLMmrYdwjXbvP2dLhoZwu81/Hd86RFZNrRU0 1xr5Y7vFw1ElqKWf1uTmJEmuJvF5L9j3yFfh7ymcf50H/LGvdULGaZ9r81Rim15VMH 4BUULsumVrnHeBwimSaTDD/NGbj2ueM3Eg/nxhkdFB1V+ajGM0vsdulmLTlFZNgwMn vt13jgmtUQuW2BcVFTQDAsGHT0Gmcoujtaha2sh9SXpVB++uDD9vrm6H7Cx6inillP sk1nXdn297tkqDQqx2pR+3iapmU6fN1aVLAWEUbQ/flcaA2j5xZmgzrdZMzAsb7osR s91m60OYKHeag== Message-ID: Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing From: Jeff Layton To: Christian Brauner Cc: Linus Torvalds , Alexander Viro , John Stultz , Thomas Gleixner , Stephen Boyd , Chandan Babu R , "Darrick J. Wong" , Dave Chinner , Theodore Ts'o , Andreas Dilger , Chris Mason , Josef Bacik , David Sterba , Hugh Dickins , Andrew Morton , Amir Goldstein , 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 09:55:09 -0400 In-Reply-To: <20231031-stark-klar-0bab5f9ab4dc@brauner> References: <20231018-mgtime-v1-0-4a7a97b1f482@kernel.org> <20231018-mgtime-v1-2-4a7a97b1f482@kernel.org> <5f96e69d438ab96099bb67d16b77583c99911caa.camel@kernel.org> <20231019-fluor-skifahren-ec74ceb6c63e@brauner> <0a1a847af4372e62000b259e992850527f587205.camel@kernel.org> <20231031-stark-klar-0bab5f9ab4dc@brauner> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-Rspamd-Queue-Id: 3CD52C0016 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: i58upbpqa3coisqf59ya4rtx89zykpdt X-HE-Tag: 1698760514-298817 X-HE-Meta: U2FsdGVkX1+YA1w44GblWpPCI1Sg7EdcA4sSjE8laMMXebTgjKdj7lyRBQaQZ5aG+npNMX8P/J69yyUDBc4oeBUnAw2BBP3M46dtPJai3FI38k34i0iF+NwZxav/oJIJjSUdDK3aRZhXuKK2EVtCxNiJLNLYsvGTw+HzeNAWabQS798unHg8zhu4DFpA//lhCAqeWrggcJ/YqXI+ffKx1vYk2XhTY89WIn1f+ZRNfhqI3ZEhAa1UZn8yaBI3XDNbu/OJwRigzzuwWxb6CbT0Y2A+NEY/a84BawRvrTrwGM6q8YKk6QPa4W5mrfrXGjgrP0Yma+w4RYUMvijzRLTmYNG6ITL7HwO+hmsReUdwP4txXx9XGF/+PizmXM8jlgjbKd31AhsQvBMgjnbtLPorjLox/MbwOvPn/uedkkKek72w64aPg758h7Ituucxc+NlWlZf+L9X5a+ipzx6hkxzV9NupT+x4+wdLvMczBCIxXWdBKG2gBAg+ykoiGftzq/LtA3/y2S6F1rsLTrZD4PTSHfXWKGkhruqyLqgyUh8EshEQgsKK8EVnayk923OsTqbSeZ14ya2aWefNmmdQ2jLdqwbU1avSz7yz2JPaWHv5CV54da1eJYH5kM/w2rWfxvehStjAaiYfxzYJ3sjQIlxnDnyibDxvPlWcUwCHJtj9vW6ANlMX27XcCIeNYn6PUZkHcZuJ8h/4p/9+rTtGe2V3BDrSd7PDWsoxr5mhvj+6/y7pMfq48AID2A4CQKRB4JLjPGHWBqOIp5XvjrfMMPSvEsrNcoc2kczPzuKEI+8xe88bNEI9CHGJnT1XVmtj3Lc/Hsrw7R/u6aPDbEMTgAAZ6kpHMoxxOBs9gmXwWClaeYvJKbtMiDOhJD4KyhQrbpiZ/qRkz8OyVUmx4VH3RuUJtUxoMSt/qx3LqBIrGkRvWd1lItana7jhluG+5RoOllVS9W98qjQql1q9yoEQb5 qo0wifrT sR8+0e1UnmfvHGQnBSG/RbHVGZCoRSNKNQz9Uwm3y1uxao7yNqT6DK25yo8HC1wqr9a1vvSvfeu/9RFdQOS5KKdjopbEoGgiIzz5Y/G/pHdcO28X+MOQIRC9xUx5A0s9UbfLhK3pplwwIZPajC63dKG8GlJSgvsAdB57+/FM5UkRGUBrocKd6HLMY+RW+QhiEBQurL0uwzOjJPEA55gxuhiS8Qik0rEReHIzebT4o9pQsxpe+Y4mzZYrlgVg+a/EOHsIJ 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 11:26 +0100, Christian Brauner wrote: > On Thu, Oct 19, 2023 at 07:28:48AM -0400, Jeff Layton wrote: > > On Thu, 2023-10-19 at 11:29 +0200, Christian Brauner wrote: > > > > Back to your earlier point though: > > > >=20 > > > > Is a global offset really a non-starter? I can see about doing some= thing > > > > per-superblock, but ktime_get_mg_coarse_ts64 should be roughly as c= heap > > > > as ktime_get_coarse_ts64. I don't see the downside there for the no= n- > > > > multigrain filesystems to call that. > > >=20 > > > I have to say that this doesn't excite me. This whole thing feels a b= it > > > hackish. I think that a change version is the way more sane way to go= . > > >=20 > >=20 > > What is it about this set that feels so much more hackish to you? Most > > of this set is pretty similar to what we had to revert. Is it just the > > timekeeper changes? Why do you feel those are a problem? >=20 > So I think that the multi-grain timestamp work was well intended but it > was ultimately a mistake. Because we added code that complicated > timestamp timestamp handling in the vfs to a point where the costs > clearly outweighed the benefits. >=20 > And I don't think that this direction is worth going into. This whole > thread ultimately boils down to complicating generic infrastructure > quite extensively for nfs to handle exposing xfs without forcing an > on-disk format change. That's even fine. >=20 > That's not a problem but in the same way I don't think the solution is > just stuffing this complexity into the vfs. IOW, if we make this a vfs > problem then at the lowest possible cost and not by changing how > timestamps work for everyone even if it's just internal. I'll point out that this last posting I did was an RFC. It was invasive to the timekeeping code, but I don't think that's a hard requirement for doing this. I do appreciate the feedback on this version of the series (particularly from Thomas who gave a great technical reason why this approach was wrong), but I don't think we necessarily have to give up on the whole idea because this particular implementation was too costly. The core idea for fixing the problem with the original series is sane, IMO. There is nothing wrong with simply making it that when we stamp a file with a fine-grained timestamp that we consider that a floor for all later timestamp updates. The only real question is how to keep that (global) fine-grained floor offset at a low cost. I think that's a solvable problem. I also believe that real, measurable fine-grained timestamp differences are worthwhile for other use cases beyond NFS. Everyone was pointing out the problems with lagging timestamps vs. make and rsync, but that's a double-edged sword. With the current always coarse-grained timestamps, the ordering of files written within the same jiffy can't be determined since their timestamps will be identical. We could conceivably change that with this series. That said, if this has no chance of ever being merged, then I won't bother working on it further, and we can try to pursue something that is (maybe) XFS-specific. Let me know, either way. -- Jeff Layton