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 us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 74A5DCD5BD6 for ; Tue, 19 Sep 2023 15:21:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695136881; h=from:from:sender: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:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=Hu6LWTHD7s/0PwwSBsDsZf9tkhzretwdfBCU6cYVdik=; b=FUDSQLu9hImwo5v6h973uCE/Hb2RyTU5L1V2wmuvZHwshtIWq/1SQU4JwMO+0em4Ys35ZH ESI/VyDONRw4Vl+I9cqSIJlP3o7TD/ke2BJSRUcUIQHirMIqeEfjuECvkbw2HSkO/wX7SM 0iiQF/qAT1XP2lRGv6F3yvw492AUAno= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-128-d9O4dKpBMIWBY0lvAudj0w-1; Tue, 19 Sep 2023 11:21:19 -0400 X-MC-Unique: d9O4dKpBMIWBY0lvAudj0w-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6939E811E7E; Tue, 19 Sep 2023 15:21:18 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3372440C2064; Tue, 19 Sep 2023 15:21:15 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id A9DAB194658D; Tue, 19 Sep 2023 15:20:59 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id B7F86194658C for ; Tue, 19 Sep 2023 14:57:31 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 97A83140E962; Tue, 19 Sep 2023 14:57:26 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast05.extmail.prod.ext.rdu2.redhat.com [10.11.55.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8FC85140E950 for ; Tue, 19 Sep 2023 14:57:26 +0000 (UTC) Received: from us-smtp-inbound-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6F94D8039CB for ; Tue, 19 Sep 2023 14:57:26 +0000 (UTC) Received: from mo4-p03-ob.smtp.rzone.de (mo4-p03-ob.smtp.rzone.de [81.169.146.174]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-678-5s7H4kJCO2GmCHDZ42atBQ-1; Tue, 19 Sep 2023 10:57:24 -0400 X-MC-Unique: 5s7H4kJCO2GmCHDZ42atBQ-1 X-RZG-CLASS-ID: mo03 X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPCifIiwFsCkzyDtyDTaOz6CkM=" Received: from nimes.localnet by smtp.strato.de (RZmta 49.8.2 AUTH) with ESMTPSA id m03934z8JEqhhDO (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 19 Sep 2023 16:52:43 +0200 (CEST) From: Bruno Haible To: Jan Kara , Xi Ruoyao , bug-gnulib@gnu.org Date: Tue, 19 Sep 2023 16:52:43 +0200 Message-ID: <4511209.uG2h0Jr0uP@nimes> In-Reply-To: <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> References: <20230807-mgctime-v7-0-d1dec143a704@kernel.org> <20230919110457.7fnmzo4nqsi43yqq@quack3> <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> MIME-Version: 1.0 X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mailman-Approved-At: Tue, 19 Sep 2023 15:20:58 +0000 Subject: Re: [Cluster-devel] [PATCH v7 12/13] ext4: switch to multigrain timestamps X-BeenThere: cluster-devel@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\[Cluster devel\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Latchesar Ionkov , Martin Brandenburg , Konstantin Komarov , linux-xfs@vger.kernel.org, "Darrick J. Wong" , Dominique Martinet , Christian Schoenebeck , ecryptfs@vger.kernel.org, linux-unionfs@vger.kernel.org, David Howells , Chris Mason , Andreas Dilger , Hans de Goede , Marc Dionne , codalist@coda.cs.cmu.edu, linux-afs@lists.infradead.org, linux-mtd@lists.infradead.org, Mike Marshall , Paulo Alcantara , linux-cifs@vger.kernel.org, Eric Van Hensbergen , bug-gnulib@gnu.org, Miklos Szeredi , Richard Weinberger , Mark Fasheh , Hugh Dickins , Tyler Hicks , cluster-devel@redhat.com, coda@cs.cmu.edu, linux-mm@kvack.org, Jeff Layton , Ilya Dryomov , Iurii Zaikin , Namjae Jeon , Trond Myklebust , Shyam Prasad N , Amir Goldstein , Kees Cook , ocfs2-devel@lists.linux.dev, Chao Yu , Josef Bacik , Tom Talpey , Tejun Heo , Yue Hu , Alexander Viro , Ronnie Sahlberg , David Sterba , Jaegeuk Kim , ceph-devel@vger.kernel.org, Xiubo Li , Gao Xiang , OGAWA Hirofumi , Jan Harkes , Christian Brauner , linux-ext4@vger.kernel.org, Theodore Ts'o , Joseph Qi , Greg Kroah-Hartman , v9fs@lists.linux.dev, ntfs3@lists.linux.dev, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Steve French , Sergey Senozhatsky , Luis Chamberlain , Jeffle Xu , devel@lists.orangefs.org, Anna Schumaker , Jan Kara , linux-fsdevel@vger.kernel.org, Andrew Morton , Sungjong Seo , linux-erofs@lists.ozlabs.org, linux-nfs@vger.kernel.org, linux-btrfs@vger.kernel.org, Joel Becker Errors-To: cluster-devel-bounces@redhat.com Sender: "Cluster-devel" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: clisp.org Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Jeff Layton wrote: > I'm not sure what we can do for this test. The nap() function is making > an assumption that the timestamp granularity will be constant, and that > isn't necessarily the case now. This is only of secondary importance, because the scenario by Jan Kara shows a much more fundamental breakage: > > The ultimate problem is that a sequence like: > > > > write(f1) > > stat(f2) > > write(f2) > > stat(f2) > > write(f1) > > stat(f1) > > > > can result in f1 timestamp to be (slightly) lower than the final f2 > > timestamp because the second write to f1 didn't bother updating the > > timestamp. That can indeed be a bit confusing to programs if they compare > > timestamps between two files. Jeff? > > > > Basically yes. f1 was last written to *after* f2 was last written to. If the timestamp of f1 is then lower than the timestamp of f2, timestamps are fundamentally broken. Many things in user-space depend on timestamps, such as build system centered around 'make', but also 'find ... -newer ...'. Bruno 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E0185CD5BCD for ; Tue, 19 Sep 2023 14:56:56 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=clisp.org header.i=@clisp.org header.a=rsa-sha256 header.s=strato-dkim-0002 header.b=fF6//tlG; dkim=fail reason="signature verification failed" header.d=clisp.org header.i=@clisp.org header.a=ed25519-sha256 header.s=strato-dkim-0003 header.b=6cNjscvM; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Rql9z2ks7z3c1Q for ; Wed, 20 Sep 2023 00:56:55 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=clisp.org header.i=@clisp.org header.a=rsa-sha256 header.s=strato-dkim-0002 header.b=fF6//tlG; dkim=pass header.d=clisp.org header.i=@clisp.org header.a=ed25519-sha256 header.s=strato-dkim-0003 header.b=6cNjscvM; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.helo=mo4-p03-ob.smtp.rzone.de (client-ip=81.169.146.173; helo=mo4-p03-ob.smtp.rzone.de; envelope-from=bruno@clisp.org; receiver=lists.ozlabs.org) X-Greylist: delayed 200 seconds by postgrey-1.37 at boromir; Wed, 20 Sep 2023 00:56:44 AEST Received: from mo4-p03-ob.smtp.rzone.de (mo4-p03-ob.smtp.rzone.de [81.169.146.173]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Rql9m5wmnz3bT3 for ; Wed, 20 Sep 2023 00:56:44 +1000 (AEST) ARC-Seal: i=1; a=rsa-sha256; t=1695135168; cv=none; d=strato.com; s=strato-dkim-0002; b=iOvNoGriAVw4BG/07a1J6uIof3CWb+6UsSmEBYX+mFyDD9f2QO4Sb9TEKH4ddRJIDy pL+qoqUJA0hBoE4nJJQRUmYRrrCYvLF6ta+aYD7VbDg0ud+mbgJHzWwSRqXYR5ZREvcs bl3KKbXR7cnsa+lCIA964mIiyg1OT/LsO/TF2FrHwu1Ap2D5rIzbspE4N+uifzZgFcIK COMHkjp45ZLpdYvm1mHL/fgF/qpLr3Ss8m6HAe7Z0ayLnnzziqQ/Ve8M0mIoGjiKEXXY DzKttOOMKEMKTf6HNofA3SeC0Zyw1CwjchqneHb1ZprMNvSTC6ly89m2hqISShU8ipWO EoEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1695135168; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=Hu6LWTHD7s/0PwwSBsDsZf9tkhzretwdfBCU6cYVdik=; b=jLy0h5BgGkHaTuA6saeMjLcT80O5PDMj8jn0r6tSDDpygqUl+dbmUNK2KZLi3xz36v g0+h6MTV2CZKqKfHLAeBYtTJJfvMQrteqrXMAf+YEKI8sPuGyydwMrWtQLIaLuExR1iT ivinSDlU9SKzh7cBAAZFAkm4tFYdkD+gAIJ/khpzKYjHS8eYquYbVcwEhmMPjRUSjsJ/ Xyda/51K4Z+JTv/CxPginA4cOQbB24NRa8A0ACkAg1iZdOLa3LuXWw69p/BQlbcrdUmk nDOjL6QI487/iHR7CcqqZHUX3CmeaRWIDTDq0lKjlF6JLf9u9E5GwBe5L4elNs6OFPWg /tRQ== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo03 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1695135168; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=Hu6LWTHD7s/0PwwSBsDsZf9tkhzretwdfBCU6cYVdik=; b=fF6//tlGfuaCILPTjW2UXofB8L0JRFiT0ta9GyxmLu/FCo/hW37Kx4K05nm1mWYfZd LVW6K8LTlLgwmAHdMNxTGjWLvM3CbMfnEWs6XpLmGxN35UXtfOopJrDhxPXSoAv1kAxk txGd6del5ZFz9i7f7QmOOLqULJAgk04E9Inurihh9CTKZ9nagVqkvJz+ZGC16HPzXO5N KF+SLwTHn+5drhMusrxLnm/2lhWMaPiVmqnEAm59XcYvwyI3nPVqmk8IusuR43iOH+6V azBsyi4ii6sFUL9a23eRkIBKS8HR3R5rirmTCU7G2fe+DZ6pQ7h6YLvKUiFekj0YaORo pC6w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1695135168; s=strato-dkim-0003; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=Hu6LWTHD7s/0PwwSBsDsZf9tkhzretwdfBCU6cYVdik=; b=6cNjscvMV8QarA/cY83EMrQy954wQIS4PLL+CFn8BrFaSsprhsBVWfpxU4X6tTSJkc jxMNKxkGefZPdprJTABg== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPCifIiwFsCkzyDtyDTaOz6CkM=" Received: from nimes.localnet by smtp.strato.de (RZmta 49.8.2 AUTH) with ESMTPSA id m03934z8JEqhhDO (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 19 Sep 2023 16:52:43 +0200 (CEST) From: Bruno Haible To: Jan Kara , Xi Ruoyao , bug-gnulib@gnu.org Subject: Re: [PATCH v7 12/13] ext4: switch to multigrain timestamps Date: Tue, 19 Sep 2023 16:52:43 +0200 Message-ID: <4511209.uG2h0Jr0uP@nimes> In-Reply-To: <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> References: <20230807-mgctime-v7-0-d1dec143a704@kernel.org> <20230919110457.7fnmzo4nqsi43yqq@quack3> <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: linux-erofs@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Linux EROFS file system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Latchesar Ionkov , Martin Brandenburg , Konstantin Komarov , linux-xfs@vger.kernel.org, "Darrick J. Wong" , Dominique Martinet , Christian Schoenebeck , ecryptfs@vger.kernel.org, linux-unionfs@vger.kernel.org, David Howells , Chris Mason , Andreas Dilger , Hans de Goede , Marc Dionne , codalist@coda.cs.cmu.edu, linux-afs@lists.infradead.org, linux-mtd@lists.infradead.org, Mike Marshall , Paulo Alcantara , linux-cifs@vger.kernel.org, Eric Van Hensbergen , bug-gnulib@gnu.org, Andreas Gruenbacher , Miklos Szeredi , Richard Weinberger , Mark Fasheh , Hugh Dickins , Benjamin Coddington , Tyler Hicks , cluster-devel@redhat.com, coda@cs.cmu.edu, linux-mm@kvack.org, Jeff Layton , Ilya Dryomov , Iurii Zaikin , Namjae Jeon , Trond Myklebust , Shyam Prasad N , Amir Goldstein , Kees Cook , ocfs2-devel@lists.linux.dev, Josef Bacik , Tom Talpey , Tejun Heo , Yue Hu , Alexander Viro , Ronnie Sahlberg , David Sterba , Jaegeuk Kim , ceph-devel@vger.kernel.org, Xiubo Li , OGAWA Hirofumi , Jan Harkes , Christian Brauner , linux-ext4@vger.kernel.org, Theodore Ts'o , Joseph Qi , Greg Kroah-Hartman , v9fs@lists.linux.dev, ntfs3@lists.linux.dev, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Steve French , Sergey Senozhatsky , Luis Chamberlain , devel@lists.orangefs.org, Anna Schumaker , Jan Kara , Bob Peterson , linux-fsdevel@vger.kernel.org, Andrew Morton , Sungjong Seo , linux-erofs@lists.ozlabs.org, linux-nfs@vger.kernel.org, linux-btrfs@vger.kernel.org, Joel Becker Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" Jeff Layton wrote: > I'm not sure what we can do for this test. The nap() function is making > an assumption that the timestamp granularity will be constant, and that > isn't necessarily the case now. This is only of secondary importance, because the scenario by Jan Kara shows a much more fundamental breakage: > > The ultimate problem is that a sequence like: > > > > write(f1) > > stat(f2) > > write(f2) > > stat(f2) > > write(f1) > > stat(f1) > > > > can result in f1 timestamp to be (slightly) lower than the final f2 > > timestamp because the second write to f1 didn't bother updating the > > timestamp. That can indeed be a bit confusing to programs if they compare > > timestamps between two files. Jeff? > > > > Basically yes. f1 was last written to *after* f2 was last written to. If the timestamp of f1 is then lower than the timestamp of f2, timestamps are fundamentally broken. Many things in user-space depend on timestamps, such as build system centered around 'make', but also 'find ... -newer ...'. Bruno 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BE2BECD5BCD for ; Tue, 19 Sep 2023 14:53:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=EMxnHPNdlt4+nP1cY3mxXZUiX0pxkmUAXcPor4hnjx8=; b=30MBqUXTwZg9dN 9hVeNo7koHGjaVerIyvinlFU5R8+O7bdDFER8H3RRBVP/jJ6d7s0R5dsnGif5OtdEiDVdGHSgBAHW gLD8J3vCNlnGyhDHfEO0JEMZShZSsQfXF7nobS9lryzjqA5q5SYr9RXmiTRSW/GlRLnanMKsQ01Le kpHAMollTiq+r3xZIwTuWw7ydjUr5jFs5t34PvQPTF9yWma61t/95s9KJx7eicVcbAOu2MK9xERHb FrZ+mt0uANBGBCXCCRrTYymXO3SX+h9FILP7w+qwwibMb11Z2F0V8/IS50MLqKVgg4eDJboMwB8LI Kx8DOXe3qXxFzPXZTEqg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qic6a-000hmZ-02; Tue, 19 Sep 2023 14:53:36 +0000 Received: from mo4-p03-ob.smtp.rzone.de ([85.215.255.101]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qic6W-000hlg-1R; Tue, 19 Sep 2023 14:53:33 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1695135168; cv=none; d=strato.com; s=strato-dkim-0002; b=iOvNoGriAVw4BG/07a1J6uIof3CWb+6UsSmEBYX+mFyDD9f2QO4Sb9TEKH4ddRJIDy pL+qoqUJA0hBoE4nJJQRUmYRrrCYvLF6ta+aYD7VbDg0ud+mbgJHzWwSRqXYR5ZREvcs bl3KKbXR7cnsa+lCIA964mIiyg1OT/LsO/TF2FrHwu1Ap2D5rIzbspE4N+uifzZgFcIK COMHkjp45ZLpdYvm1mHL/fgF/qpLr3Ss8m6HAe7Z0ayLnnzziqQ/Ve8M0mIoGjiKEXXY DzKttOOMKEMKTf6HNofA3SeC0Zyw1CwjchqneHb1ZprMNvSTC6ly89m2hqISShU8ipWO EoEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1695135168; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=Hu6LWTHD7s/0PwwSBsDsZf9tkhzretwdfBCU6cYVdik=; b=jLy0h5BgGkHaTuA6saeMjLcT80O5PDMj8jn0r6tSDDpygqUl+dbmUNK2KZLi3xz36v g0+h6MTV2CZKqKfHLAeBYtTJJfvMQrteqrXMAf+YEKI8sPuGyydwMrWtQLIaLuExR1iT ivinSDlU9SKzh7cBAAZFAkm4tFYdkD+gAIJ/khpzKYjHS8eYquYbVcwEhmMPjRUSjsJ/ Xyda/51K4Z+JTv/CxPginA4cOQbB24NRa8A0ACkAg1iZdOLa3LuXWw69p/BQlbcrdUmk nDOjL6QI487/iHR7CcqqZHUX3CmeaRWIDTDq0lKjlF6JLf9u9E5GwBe5L4elNs6OFPWg /tRQ== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo03 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1695135168; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=Hu6LWTHD7s/0PwwSBsDsZf9tkhzretwdfBCU6cYVdik=; b=fF6//tlGfuaCILPTjW2UXofB8L0JRFiT0ta9GyxmLu/FCo/hW37Kx4K05nm1mWYfZd LVW6K8LTlLgwmAHdMNxTGjWLvM3CbMfnEWs6XpLmGxN35UXtfOopJrDhxPXSoAv1kAxk txGd6del5ZFz9i7f7QmOOLqULJAgk04E9Inurihh9CTKZ9nagVqkvJz+ZGC16HPzXO5N KF+SLwTHn+5drhMusrxLnm/2lhWMaPiVmqnEAm59XcYvwyI3nPVqmk8IusuR43iOH+6V azBsyi4ii6sFUL9a23eRkIBKS8HR3R5rirmTCU7G2fe+DZ6pQ7h6YLvKUiFekj0YaORo pC6w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1695135168; s=strato-dkim-0003; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=Hu6LWTHD7s/0PwwSBsDsZf9tkhzretwdfBCU6cYVdik=; b=6cNjscvMV8QarA/cY83EMrQy954wQIS4PLL+CFn8BrFaSsprhsBVWfpxU4X6tTSJkc jxMNKxkGefZPdprJTABg== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPCifIiwFsCkzyDtyDTaOz6CkM=" Received: from nimes.localnet by smtp.strato.de (RZmta 49.8.2 AUTH) with ESMTPSA id m03934z8JEqhhDO (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 19 Sep 2023 16:52:43 +0200 (CEST) From: Bruno Haible To: Jan Kara , Xi Ruoyao , bug-gnulib@gnu.org Cc: Alexander Viro , Christian Brauner , Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck , David Howells , Marc Dionne , Chris Mason , Josef Bacik , David Sterba , Xiubo Li , Ilya Dryomov , Jan Harkes , coda@cs.cmu.edu, Tyler Hicks , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Namjae Jeon , Sungjong Seo , Jan Kara , Theodore Ts'o , Andreas Dilger , Jaegeuk Kim , OGAWA Hirofumi , Miklos Szeredi , Bob Peterson , Andreas Gruenbacher , Greg Kroah-Hartman , Tejun Heo , Trond Myklebust , Anna Schumaker , Konstantin Komarov , Mark Fasheh , Joel Becker , Joseph Qi , Mike Marshall , Martin Brandenburg , Luis Chamberlain , Kees Cook , Iurii Zaikin , Steve French , Paulo Alcantara , Ronnie Sahlberg , Shyam Prasad N , Tom Talpey , Sergey Senozhatsky , Richard Weinberger , Hans de Goede , Hugh Dickins , Andrew Morton , Amir Goldstein , "Darrick J. Wong" , Benjamin Coddington , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, v9fs@lists.linux.dev, linux-afs@lists.infradead.org, linux-btrfs@vger.kernel.org, ceph-devel@vger.kernel.org, codalist@coda.cs.cmu.edu, ecryptfs@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, linux-nfs@vger.kernel.org, ntfs3@lists.linux.dev, ocfs2-devel@lists.linux.dev, devel@lists.orangefs.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-mtd@lists.infradead.org, linux-mm@kvack.org, linux-unionfs@vger.kernel.org, linux-xfs@vger.kernel.org, bug-gnulib@gnu.org, Jeff Layton Subject: Re: [PATCH v7 12/13] ext4: switch to multigrain timestamps Date: Tue, 19 Sep 2023 16:52:43 +0200 Message-ID: <4511209.uG2h0Jr0uP@nimes> In-Reply-To: <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> References: <20230807-mgctime-v7-0-d1dec143a704@kernel.org> <20230919110457.7fnmzo4nqsi43yqq@quack3> <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230919_075332_654785_FCBFBB9C X-CRM114-Status: GOOD ( 13.98 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org Jeff Layton wrote: > I'm not sure what we can do for this test. The nap() function is making > an assumption that the timestamp granularity will be constant, and that > isn't necessarily the case now. This is only of secondary importance, because the scenario by Jan Kara shows a much more fundamental breakage: > > The ultimate problem is that a sequence like: > > > > write(f1) > > stat(f2) > > write(f2) > > stat(f2) > > write(f1) > > stat(f1) > > > > can result in f1 timestamp to be (slightly) lower than the final f2 > > timestamp because the second write to f1 didn't bother updating the > > timestamp. That can indeed be a bit confusing to programs if they compare > > timestamps between two files. Jeff? > > > > Basically yes. f1 was last written to *after* f2 was last written to. If the timestamp of f1 is then lower than the timestamp of f2, timestamps are fundamentally broken. Many things in user-space depend on timestamps, such as build system centered around 'make', but also 'find ... -newer ...'. Bruno ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mo4-p03-ob.smtp.rzone.de (mo4-p03-ob.smtp.rzone.de [81.169.146.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A30A13B784; Tue, 19 Sep 2023 14:59:04 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1695135168; cv=none; d=strato.com; s=strato-dkim-0002; b=iOvNoGriAVw4BG/07a1J6uIof3CWb+6UsSmEBYX+mFyDD9f2QO4Sb9TEKH4ddRJIDy pL+qoqUJA0hBoE4nJJQRUmYRrrCYvLF6ta+aYD7VbDg0ud+mbgJHzWwSRqXYR5ZREvcs bl3KKbXR7cnsa+lCIA964mIiyg1OT/LsO/TF2FrHwu1Ap2D5rIzbspE4N+uifzZgFcIK COMHkjp45ZLpdYvm1mHL/fgF/qpLr3Ss8m6HAe7Z0ayLnnzziqQ/Ve8M0mIoGjiKEXXY DzKttOOMKEMKTf6HNofA3SeC0Zyw1CwjchqneHb1ZprMNvSTC6ly89m2hqISShU8ipWO EoEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1695135168; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=Hu6LWTHD7s/0PwwSBsDsZf9tkhzretwdfBCU6cYVdik=; b=jLy0h5BgGkHaTuA6saeMjLcT80O5PDMj8jn0r6tSDDpygqUl+dbmUNK2KZLi3xz36v g0+h6MTV2CZKqKfHLAeBYtTJJfvMQrteqrXMAf+YEKI8sPuGyydwMrWtQLIaLuExR1iT ivinSDlU9SKzh7cBAAZFAkm4tFYdkD+gAIJ/khpzKYjHS8eYquYbVcwEhmMPjRUSjsJ/ Xyda/51K4Z+JTv/CxPginA4cOQbB24NRa8A0ACkAg1iZdOLa3LuXWw69p/BQlbcrdUmk nDOjL6QI487/iHR7CcqqZHUX3CmeaRWIDTDq0lKjlF6JLf9u9E5GwBe5L4elNs6OFPWg /tRQ== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo03 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1695135168; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=Hu6LWTHD7s/0PwwSBsDsZf9tkhzretwdfBCU6cYVdik=; b=fF6//tlGfuaCILPTjW2UXofB8L0JRFiT0ta9GyxmLu/FCo/hW37Kx4K05nm1mWYfZd LVW6K8LTlLgwmAHdMNxTGjWLvM3CbMfnEWs6XpLmGxN35UXtfOopJrDhxPXSoAv1kAxk txGd6del5ZFz9i7f7QmOOLqULJAgk04E9Inurihh9CTKZ9nagVqkvJz+ZGC16HPzXO5N KF+SLwTHn+5drhMusrxLnm/2lhWMaPiVmqnEAm59XcYvwyI3nPVqmk8IusuR43iOH+6V azBsyi4ii6sFUL9a23eRkIBKS8HR3R5rirmTCU7G2fe+DZ6pQ7h6YLvKUiFekj0YaORo pC6w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1695135168; s=strato-dkim-0003; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=Hu6LWTHD7s/0PwwSBsDsZf9tkhzretwdfBCU6cYVdik=; b=6cNjscvMV8QarA/cY83EMrQy954wQIS4PLL+CFn8BrFaSsprhsBVWfpxU4X6tTSJkc jxMNKxkGefZPdprJTABg== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPCifIiwFsCkzyDtyDTaOz6CkM=" Received: from nimes.localnet by smtp.strato.de (RZmta 49.8.2 AUTH) with ESMTPSA id m03934z8JEqhhDO (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 19 Sep 2023 16:52:43 +0200 (CEST) From: Bruno Haible To: Jan Kara , Xi Ruoyao , bug-gnulib@gnu.org Cc: Alexander Viro , Christian Brauner , Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck , David Howells , Marc Dionne , Chris Mason , Josef Bacik , David Sterba , Xiubo Li , Ilya Dryomov , Jan Harkes , coda@cs.cmu.edu, Tyler Hicks , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Namjae Jeon , Sungjong Seo , Jan Kara , Theodore Ts'o , Andreas Dilger , Jaegeuk Kim , OGAWA Hirofumi , Miklos Szeredi , Bob Peterson , Andreas Gruenbacher , Greg Kroah-Hartman , Tejun Heo , Trond Myklebust , Anna Schumaker , Konstantin Komarov , Mark Fasheh , Joel Becker , Joseph Qi , Mike Marshall , Martin Brandenburg , Luis Chamberlain , Kees Cook , Iurii Zaikin , Steve French , Paulo Alcantara , Ronnie Sahlberg , Shyam Prasad N , Tom Talpey , Sergey Senozhatsky , Richard Weinberger , Hans de Goede , Hugh Dickins , Andrew Morton , Amir Goldstein , "Darrick J. Wong" , Benjamin Coddington , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, v9fs@lists.linux.dev, linux-afs@lists.infradead.org, linux-btrfs@vger.kernel.org, ceph-devel@vger.kernel.org, codalist@coda.cs.cmu.edu, ecryptfs@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, linux-nfs@vger.kernel.org, ntfs3@lists.linux.dev, ocfs2-devel@lists.linux.dev, devel@lists.orangefs.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-mtd@lists.infradead.org, linux-mm@kvack.org, linux-unionfs@vger.kernel.org, linux-xfs@vger.kernel.org, bug-gnulib@gnu.org, Jeff Layton Subject: Re: [PATCH v7 12/13] ext4: switch to multigrain timestamps Date: Tue, 19 Sep 2023 16:52:43 +0200 Message-ID: <4511209.uG2h0Jr0uP@nimes> In-Reply-To: <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> References: <20230807-mgctime-v7-0-d1dec143a704@kernel.org> <20230919110457.7fnmzo4nqsi43yqq@quack3> <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> Precedence: bulk X-Mailing-List: ntfs3@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Jeff Layton wrote: > I'm not sure what we can do for this test. The nap() function is making > an assumption that the timestamp granularity will be constant, and that > isn't necessarily the case now. This is only of secondary importance, because the scenario by Jan Kara shows a much more fundamental breakage: > > The ultimate problem is that a sequence like: > > > > write(f1) > > stat(f2) > > write(f2) > > stat(f2) > > write(f1) > > stat(f1) > > > > can result in f1 timestamp to be (slightly) lower than the final f2 > > timestamp because the second write to f1 didn't bother updating the > > timestamp. That can indeed be a bit confusing to programs if they compare > > timestamps between two files. Jeff? > > > > Basically yes. f1 was last written to *after* f2 was last written to. If the timestamp of f1 is then lower than the timestamp of f2, timestamps are fundamentally broken. Many things in user-space depend on timestamps, such as build system centered around 'make', but also 'find ... -newer ...'. Bruno 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 3A4EACD5BCD for ; Tue, 19 Sep 2023 14:53:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B0AA26B054F; Tue, 19 Sep 2023 10:52:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AE22A6B0550; Tue, 19 Sep 2023 10:52:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 982E56B0551; Tue, 19 Sep 2023 10:52:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 863EC6B054F for ; Tue, 19 Sep 2023 10:52:59 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 5E06A160444 for ; Tue, 19 Sep 2023 14:52:59 +0000 (UTC) X-FDA: 81253639278.24.B92AD8A Received: from mo4-p03-ob.smtp.rzone.de (mo4-p03-ob.smtp.rzone.de [81.169.146.172]) by imf11.hostedemail.com (Postfix) with ESMTP id 3C14E40003 for ; Tue, 19 Sep 2023 14:52:56 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=clisp.org header.s=strato-dkim-0002 header.b="fF6//tlG"; dkim=pass header.d=clisp.org header.s=strato-dkim-0003 header.b=6cNjscvM; dmarc=none; arc=pass ("strato.com:s=strato-dkim-0002:i=1"); spf=none (imf11.hostedemail.com: domain of bruno@clisp.org has no SPF policy when checking 81.169.146.172) smtp.mailfrom=bruno@clisp.org ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695135177; 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=Hu6LWTHD7s/0PwwSBsDsZf9tkhzretwdfBCU6cYVdik=; b=X/yS6VC6umZaRejjW9xA6KF7WKEF/TjiD8z1ROMXxvt18CpBvOPeRE6XbUq5dZ4rhjCyjj Im+nilSBEQy16WBYbKdBk9aLWPcOoZWnst93EIeUhe2Yl/j6atHVQCLxxZLov/oS7xbvQr tSlPfbIgXoyngTh9QMSP4tLhzGrMjig= ARC-Authentication-Results: i=2; imf11.hostedemail.com; dkim=pass header.d=clisp.org header.s=strato-dkim-0002 header.b="fF6//tlG"; dkim=pass header.d=clisp.org header.s=strato-dkim-0003 header.b=6cNjscvM; dmarc=none; arc=pass ("strato.com:s=strato-dkim-0002:i=1"); spf=none (imf11.hostedemail.com: domain of bruno@clisp.org has no SPF policy when checking 81.169.146.172) smtp.mailfrom=bruno@clisp.org ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1695135177; a=rsa-sha256; cv=pass; b=6OxRquZkgcBRbl8f8ifWzu/WokT6cA8WK4aQWZ0PRXj/SyPcrEnkCoI4KlZowZ73XJV6g5 8QNWQrg7OfH0qrWfJluUHSrB9ZSkUlPq6h7gDXAMzzeZOX4Kq8b+s48aV13rNhLu+VCXb7 hayUe9LzWa6+K9/3myIpHe6l6ahyqPg= ARC-Seal: i=1; a=rsa-sha256; t=1695135168; cv=none; d=strato.com; s=strato-dkim-0002; b=iOvNoGriAVw4BG/07a1J6uIof3CWb+6UsSmEBYX+mFyDD9f2QO4Sb9TEKH4ddRJIDy pL+qoqUJA0hBoE4nJJQRUmYRrrCYvLF6ta+aYD7VbDg0ud+mbgJHzWwSRqXYR5ZREvcs bl3KKbXR7cnsa+lCIA964mIiyg1OT/LsO/TF2FrHwu1Ap2D5rIzbspE4N+uifzZgFcIK COMHkjp45ZLpdYvm1mHL/fgF/qpLr3Ss8m6HAe7Z0ayLnnzziqQ/Ve8M0mIoGjiKEXXY DzKttOOMKEMKTf6HNofA3SeC0Zyw1CwjchqneHb1ZprMNvSTC6ly89m2hqISShU8ipWO EoEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1695135168; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=Hu6LWTHD7s/0PwwSBsDsZf9tkhzretwdfBCU6cYVdik=; b=jLy0h5BgGkHaTuA6saeMjLcT80O5PDMj8jn0r6tSDDpygqUl+dbmUNK2KZLi3xz36v g0+h6MTV2CZKqKfHLAeBYtTJJfvMQrteqrXMAf+YEKI8sPuGyydwMrWtQLIaLuExR1iT ivinSDlU9SKzh7cBAAZFAkm4tFYdkD+gAIJ/khpzKYjHS8eYquYbVcwEhmMPjRUSjsJ/ Xyda/51K4Z+JTv/CxPginA4cOQbB24NRa8A0ACkAg1iZdOLa3LuXWw69p/BQlbcrdUmk nDOjL6QI487/iHR7CcqqZHUX3CmeaRWIDTDq0lKjlF6JLf9u9E5GwBe5L4elNs6OFPWg /tRQ== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo03 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1695135168; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=Hu6LWTHD7s/0PwwSBsDsZf9tkhzretwdfBCU6cYVdik=; b=fF6//tlGfuaCILPTjW2UXofB8L0JRFiT0ta9GyxmLu/FCo/hW37Kx4K05nm1mWYfZd LVW6K8LTlLgwmAHdMNxTGjWLvM3CbMfnEWs6XpLmGxN35UXtfOopJrDhxPXSoAv1kAxk txGd6del5ZFz9i7f7QmOOLqULJAgk04E9Inurihh9CTKZ9nagVqkvJz+ZGC16HPzXO5N KF+SLwTHn+5drhMusrxLnm/2lhWMaPiVmqnEAm59XcYvwyI3nPVqmk8IusuR43iOH+6V azBsyi4ii6sFUL9a23eRkIBKS8HR3R5rirmTCU7G2fe+DZ6pQ7h6YLvKUiFekj0YaORo pC6w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1695135168; s=strato-dkim-0003; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=Hu6LWTHD7s/0PwwSBsDsZf9tkhzretwdfBCU6cYVdik=; b=6cNjscvMV8QarA/cY83EMrQy954wQIS4PLL+CFn8BrFaSsprhsBVWfpxU4X6tTSJkc jxMNKxkGefZPdprJTABg== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPCifIiwFsCkzyDtyDTaOz6CkM=" Received: from nimes.localnet by smtp.strato.de (RZmta 49.8.2 AUTH) with ESMTPSA id m03934z8JEqhhDO (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 19 Sep 2023 16:52:43 +0200 (CEST) From: Bruno Haible To: Jan Kara , Xi Ruoyao , bug-gnulib@gnu.org Cc: Alexander Viro , Christian Brauner , Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck , David Howells , Marc Dionne , Chris Mason , Josef Bacik , David Sterba , Xiubo Li , Ilya Dryomov , Jan Harkes , coda@cs.cmu.edu, Tyler Hicks , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Namjae Jeon , Sungjong Seo , Jan Kara , Theodore Ts'o , Andreas Dilger , Jaegeuk Kim , OGAWA Hirofumi , Miklos Szeredi , Bo b Peterson , Andreas Gruenbacher , Greg Kroah-Hartman , Tejun Heo , Trond Myklebust , Anna Schumaker , Konstantin Komarov , Mark Fasheh , Joel Becker , Joseph Qi , Mike Marshall , Martin Brandenburg , Luis Chamberlain , Kees Cook , Iurii Zaikin , Steve French , Paulo Alcantara , Ronnie Sahlberg , Shyam Prasad N , Tom Talpey , Sergey Senozhatsky , Richard Weinberger , Hans de Goede , Hugh Dickins , Andrew Morton , Amir Goldstein <"amir73i l"@gmail.com>, "Darrick J. Wong" , Benjamin Coddington , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, v9fs@lists.linux.dev, linux-afs@lists.infradead.org, linux-btrfs@vger.kernel.org, ceph-devel@vger.kernel.org, codalist@coda.cs.cmu.edu, ecryptfs@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, linux-nfs@vger.kernel.org, ntfs3@lists.linux.dev, ocfs2-devel@lists.linux.dev, devel@lists.orangefs.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-mtd@lists.infradead.org, linux-mm@kvack.org, linux-unionfs@vger.kernel.org, linux-xfs@vger.kernel.org, bug-gnulib@gnu.org, Jeff Layton Subject: Re: [PATCH v7 12/13] ext4: switch to multigrain timestamps Date: Tue, 19 Sep 2023 16:52:43 +0200 Message-ID: <4511209.uG2h0Jr0uP@nimes> In-Reply-To: <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> References: <20230807-mgctime-v7-0-d1dec143a704@kernel.org> <20230919110457.7fnmzo4nqsi43yqq@quack3> <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 3C14E40003 X-Stat-Signature: hmdtctnnjwt6bc1h9beykgrafa31uyqo X-Rspam-User: X-HE-Tag: 1695135176-188737 X-HE-Meta: U2FsdGVkX19P2Ao+sGlGxb4acqEXRw43RHGhsKGIPHgLly47ZsoQVHPLPk0LD1m436NdgkL7yknSJTJQxgz/P+UnzRj1QT23h7vvrADVEYIJQVlZYovcqlpVfk6j94lj3+m1Bdla+HACgC0x/Si/fOK27rpxVMWvyZqcDno9pj373yALw43jBqcMcqZcq3F+D95pq+xyVnyqFSWZ1R0SGao6wNMXwKPGB/TKqCikTGDVcgajqqhE5CztDiIV3UzdZi/qST9r9yEO7VYEWOJhYsPG4voSss4qazc03/YFhUoi8HiCh2ZLAZaMYx5QRSulfaTY2ihWVLoVxrplMpIvXzJ4C2V4szwclP2G2aLjfRDS4Zpr7FguhlxyxHQLQknyZlK/KtO58iiXTPk7Ra0ulRZZ/D+2FU5ALORTHoDSC9xxi3OlIar97zDo/Zwm6AiwirMg21y5PPdle/MxoZrNTauju99OEs+WmTv7oNNo98RL4QxkZcKriL0W809rHrcr1QdTKcHhaiOofG651ivN1/+oZT9XDr4A9fhzI1b/6266sJAcKI0CYdi7Jg7yzUsL3zgN4jnueYJmmXvgtzECSy7DO44Glvzez67lrBybBAL1f6h0z0sGLr4tAHNxHdUw9Pd+yCfLZBkLHWqrT0gReFoTeCYJSYD48USxxHcoVgdiUffsyMjYpLf1bbpNNf/MN/0+F6KKlhgp/pg2ViNU9PxNyCYNKjYMGtB88P0mh7/q/GyR1dGrik1R71TB672u3/SSXJpttfGDCOhvQh0Zmj01rJxCC2HJnl1y2uqzSEHnwKnRE3IfpQrn0OR9LIiYkWl0nr1Q4T6/zvSfCdwbqbDBqs/QdN44i5uXOtfNP38p0K0B/So3wXQ6ws0L0B8LIERDN3pr1LAo5Jye2dklFW2zRJFeaYfkfvLm7Ee75gwU7CanTv5G0cjBMyHGjeWoZuflAP4fH/tvnMZJJf5 Dn1K0obA DMgtEOkw0wxjOJKS6KikWyCdeAJvGj3q20M1jB3kC1QNZM9c8yn7EY4dOrmB+bmTqoiixnea3gYpTDPUKznPN9g+B52ljyA83pDs28CGiAZ6msjC++VN+tnLtOdc3wP5yd+uNAlFsaCsLui65J0Qj7k0Nit294SC0qeOVbJbZeQtJPwY8+pS8ZVzS3ec9oZ7B3ImqG3wMfsIAehhpfhxyrk96xf/rxSZvUEuSkEPC8FIFlPIU45gxNnDHcNe1BuqPNtdBBsa9JsYiG3w= 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: Jeff Layton wrote: > I'm not sure what we can do for this test. The nap() function is making > an assumption that the timestamp granularity will be constant, and that > isn't necessarily the case now. This is only of secondary importance, because the scenario by Jan Kara shows a much more fundamental breakage: > > The ultimate problem is that a sequence like: > > > > write(f1) > > stat(f2) > > write(f2) > > stat(f2) > > write(f1) > > stat(f1) > > > > can result in f1 timestamp to be (slightly) lower than the final f2 > > timestamp because the second write to f1 didn't bother updating the > > timestamp. That can indeed be a bit confusing to programs if they compare > > timestamps between two files. Jeff? > > > > Basically yes. f1 was last written to *after* f2 was last written to. If the timestamp of f1 is then lower than the timestamp of f2, timestamps are fundamentally broken. Many things in user-space depend on timestamps, such as build system centered around 'make', but also 'find ... -newer ...'. Bruno