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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6DFAFC41535 for ; Tue, 31 Oct 2023 10:26:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343944AbjJaK0v (ORCPT ); Tue, 31 Oct 2023 06:26:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36226 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343687AbjJaK0e (ORCPT ); Tue, 31 Oct 2023 06:26:34 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8332EA9; Tue, 31 Oct 2023 03:26:31 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7A722C433CD; Tue, 31 Oct 2023 10:26:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698747991; bh=oub4W8UR9eJvRxgd0x2K3FAODzLnOQX75kkj3Rb+xzQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CBQ79pKptpDj7180sdV3SpAcAZvHyawpezclc+dj2iFMxLVXbCbeH5YfqE4WcuoSQ /IEC+3qoroTC2lIkVBcGC1DX6llrEm61HMJO99f+TerLtsheVQsLE9AfPYgLhim3il BwxCV8atgTPe56WKD61JOc4sLVO6kH2+d24WzaTAZ7BS3WWrCrsQF+tGOsjU+AaLRA sYchDKCcENZca1LRCxGxYqUCuu6xVqJq2heeguzA/O1G/LaEcErOyMUJBqHuHm/NWG odXeR9D7iD7TDRylyP2HU+NvC56rx+jfWJiWfYSK0levv1XvEdMBDZqRx+QV8N29Ze bO3o0pYhWGntQ== Date: Tue, 31 Oct 2023 11:26:22 +0100 From: Christian Brauner To: Jeff Layton 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 Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0a1a847af4372e62000b259e992850527f587205.camel@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: > > > > > > Is a global offset really a non-starter? I can see about doing something > > > 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. > > > > 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. > > > > 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? 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. 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. 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.