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 F2A36CE7A8A for ; Sun, 24 Sep 2023 10:26:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229899AbjIXK1C (ORCPT ); Sun, 24 Sep 2023 06:27:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229508AbjIXK1B (ORCPT ); Sun, 24 Sep 2023 06:27:01 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8F78E7; Sun, 24 Sep 2023 03:26:55 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4694C433C8; Sun, 24 Sep 2023 10:26:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695551215; bh=7cLQg98m6+9eW+6GoIBst+Vv8YYV01tpEGvVQDPRTYw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DOLcmHJ2gPMA313OsvVYvG5W3of3l46X2wWZ0KdIE4Shwn1QyDv/5P8e9CtzzoIgH DktH2T+W9CFC9FKWVRPhEv1jNL8bvxyV3GkoXVNgg/k+t7VadSe+8/wA6xJwdc/MVa pHz55+R561UZc/w5H3sPPCYeSoI+t3anl/Bdln//jM0FoyhL3qrQb8N1fSthtK2rt0 +RnffvW95OeLAqRWeWnNIYh+hvb84eEjwwc8rcNULX3+E/hOJ7M1aG27h1l/53ADUI IaT8xh1/gMFL8uAtsQ3r13hEedAAQHpZ3O5R0crwtpqel0pFpdcVYhVKFOASEayD7x 2Ovsk2WTipgSw== Date: Sun, 24 Sep 2023 12:26:51 +0200 From: Christian Brauner To: Amir Goldstein Cc: Linus Torvalds , Jeff Layton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Jan Kara , "Darrick J. Wong" Subject: Re: [GIT PULL v2] timestamp fixes Message-ID: <20230924-trial-dennoch-e641f0e0ee1b@brauner> References: <20230921-umgekehrt-buden-a8718451ef7c@brauner> <0d006954b698cb1cea3a93c1662b5913a0ded3b1.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org > > Those workloads are broken garbage, and we should *not* use that kind > > of sh*t to decide on VFS internals. > > > > Sorry, I phrased it completely wrong. Thanks for clearing this up. I had just formulated my own reply but I'll happily delete it. :) > The workloads don't expect 1ns resolution. Yes, they don't. In the revert explanation I just used that number to illustrate the general ordering problem. The workload that surfaced the issue is just plain weird of course but it points to a more general ordering problem. > The workloads just compare timestamps of objects and expect some sane > not-before ordering rules. Yes. > If user visible timestamps are truncated to 100ns all is good. Yes.