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 ACF84CDB465 for ; Thu, 19 Oct 2023 11:28:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 385208D0199; Thu, 19 Oct 2023 07:28:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 335608D0019; Thu, 19 Oct 2023 07:28:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 224388D0199; Thu, 19 Oct 2023 07:28:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 133D88D0019 for ; Thu, 19 Oct 2023 07:28:57 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id CF8BD140410 for ; Thu, 19 Oct 2023 11:28:56 +0000 (UTC) X-FDA: 81361989072.04.2CC8034 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf30.hostedemail.com (Postfix) with ESMTP id CE0038001E for ; Thu, 19 Oct 2023 11:28:54 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HBA7HSvG; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf30.hostedemail.com: domain of jlayton@kernel.org designates 145.40.68.75 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=1697714935; 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=frnWz1sFRBQuYonb5RmQwPk5jf/lF7GP4WLN8JSXa7M=; b=Ak1oN1R25MD7fAWlz9DqPFwm1ut1HQsILFcMLn+S1OQUybKkSxWMFnbv9W7dR0CSTGTgF2 kk34Fl1YynWFwBR6VGjW/CLOEjMPZ3vLej0d+yKXP21MhfftAnuIn+sPuFCbkjtbis6TwC +/WSusd6tGkcA/A+qYmtJqDhfn9BhTw= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HBA7HSvG; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf30.hostedemail.com: domain of jlayton@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=jlayton@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697714935; a=rsa-sha256; cv=none; b=isRc9xhV08Ux3jRKEmOmuJx511amkcq8nYOY42HFDlAHT1X7GcDjZ+BOgXELLzyl5Cp6js lanXcmzq35tPd9kYI9wwURZUBM9/2j7aDoZ5YLky8dB55USBUUSr0oC8dCe3FhZ9L3CLeK 2wm/vsQ5XK61vxi3Q5tg3AOn3A8dnJU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id E6E92B827E0; Thu, 19 Oct 2023 11:28:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18A89C433C7; Thu, 19 Oct 2023 11:28:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697714932; bh=frnWz1sFRBQuYonb5RmQwPk5jf/lF7GP4WLN8JSXa7M=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=HBA7HSvGoIRn7e8pKkbEW9dLvkhR6UbP9YryXoyb0yOjeGBF3+t2/uXVAqhO8+5XZ g0zjGzFjnXF/LfXiIIdiO8O+s2WH1DbOU5PxZHMy5BGmXDF1pxMFXw5belLfcYtN7H 99/gEqDLZv0OG5nrh2/sMZTcmW/PdfrhuOSXelnXPQnJC1BordF3CwVUQNbDT7FTNG nn177O3fNCLQE2ooDHVnWEyFQh2gHAsFOuYPrlz1K/YrfOpU/ht9vUd3N/Bwu8Bm8m 10CRzoGlUcfNESgswU4BLKxSdAsGBM5bqEhUzQbS/iUBrFcZX0/oc11HUt7teGBqNa 7K8NLvWb7IZrw== Message-ID: <0a1a847af4372e62000b259e992850527f587205.camel@kernel.org> Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing From: Jeff Layton To: Christian Brauner , Linus Torvalds Cc: 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: Thu, 19 Oct 2023 07:28:48 -0400 In-Reply-To: <20231019-fluor-skifahren-ec74ceb6c63e@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> 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-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: CE0038001E X-Stat-Signature: 6bjxqdzftqddpfi7ahitnbothhqowh4y X-HE-Tag: 1697714934-176372 X-HE-Meta: U2FsdGVkX19cYwZKGpdINYEM3x5Cf3/1UTSzPf3zzKKFq/sNHsm5oRl4GerQODWp76ivKxaYBiagBMSiQ/AxAFCP+Kf0AFu/qOEznPhxjLsFiy35rRPenJtFEBrIPUC8WJrdDdIXStSpSTIrA4D1xqQ5BdJ3K3MBdZSf5T2faWYYr3kTfNUwZ7cAsgF2lU7ZazMK4K/vTh9zBnGVRKRqvtvbDHWX2IdzV9vtpsHRGphVyOhjhyH4ZPkrR2INqcY0i1XANl1OGM8HI349t06+nUAEmANu7gbhj0M5XchTWoM72QyyQrqVPtFaAI28PWSVd6Kx5nQj1DMFHcgH2fo2tFHQDzDIUX7+V/S0tIp4voUYSPp8xdCFdsu7y6sjTkdnWT38kHru13rXzlbqy+wJnZZ1fR775L0chnB1aRWjK7FwtmYT9t1jQVyRLmAK7svhB3DtewBpMOjnNOGmQZGdtXYcpSQGSRP5i2Clv70Xsw47PBf/lkWxY/Z5mES6r7lebH/6b7Yk+g66KNUeIEKpxKBpBwDrGTsm1KTSmgMIKiAGiEa/OC2ijOP7Y41GiNsAmJdqnBJFPdy2Rc6Rodot0ROvNd3OEHljwjFXEd1tBOSuAORKTQ3LcPFv7Ba+cBFgSRlikhqPBo84W5s7DQbKMsFJ6+/rPVwX+fqU4rIPC2bvJjxLmePHYfIA1Ol5ZqWrvpJLKdn3bZY6nRcDY7BCBHaKaqwdbahOoFapuN/ZQ0Z8lswQ9vpQJlotN9WzDjZAVdKiTDuJPoSPX+IIHDHojH+w00v2BUvmoVPg5NDRMFSbucRg2PzvRbjzjSWqERFParFJxC1huSbFFjRJ3LwDVf7bZKgqFBjBs4AEDczQ5sLKN0HXqqG/vJEWzzkwu2h330ElVAe9rxuvjDduu0QCaNTSAczUn+ACRgCXIX9gLRF7hdu9tmQUmDa2vgtBZCt7RZS7Pra2YoGeXYglJTy xqNPJO+0 24Cb9eCgsgz9CKf2tGRzKHoYi8jzGPxj36sl5GWWXCLyUHwLenP0yvW/y3QcQGN+zZFkV+cYwVw760YcVB/jocj9fLrPJND+m4tK/ghuQz//aktiI/V2rQwhETyEqYTtxTuVFsQsivBDJJTqIdQb5Q9lHX4lrTMVIMhP5kr4K8JKu2qTvRoWH86MVTvlwxN4P2uonUl00LywsgXdoUOMVO3+wA9S9+yUO9ao6qJt+YZEmhniW6I3/3fpHwg== 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: 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 somethin= g > > per-superblock, but ktime_get_mg_coarse_ts64 should be roughly as cheap > > as ktime_get_coarse_ts64. I don't see the downside there for the non- > > multigrain filesystems to call that. >=20 > I have to say that this doesn't excite me. This whole thing feels a bit > hackish. I think that a change version is the way more sane way to go. >=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 > > On another note: maybe I need to put this behind a Kconfig option > > initially too? >=20 > So can we for a second consider not introducing fine-grained timestamps > at all. We let NFSv3 live with the cache problem it's been living with > forever. >=20 > And for NFSv4 we actually do introduce a proper i_version for all > filesystems that matter to it. >=20 > What filesystems exactly don't expose a proper i_version and what does > prevent them from adding one or fixing it? Certainly we can drop this series altogether if that's the consensus. The main exportable filesystem that doesn't have a suitable change counter now is XFS. Fixing it will require an on-disk format change to accommodate a new version counter that doesn't increment on atime updates. This is something the XFS folks were specifically looking to avoid, but maybe that's the simpler option. There is also bcachefs which I don't think has a change attr yet. They'd also likely need a on-disk format change, but hopefully that's a easier thing to do there since it's a brand new filesystem. There are a smattering of lesser-used local filesystems (f2fs, nilfs2, etc.) that have no i_version support. Multigrain timestamps would make it simple to add better change attribute support there, but they can (in principle) all undergo an on-disk format change too if they decide to add one. Then there are filesystems like ntfs that are exportable, but where we can't extend the on-disk format. Those could probably benefit from multigrain timestamps, but those are much lower priority. Not many people sharing their NTFS filesystem via NFS anyway. --=20 Jeff Layton