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.129.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 AE682CE79A8 for ; Tue, 19 Sep 2023 17:30:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695144646; 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=2YOWI6/JAFOB4t8+Jl1G0UAU2WJNOEKR+ozWrF+wCHw=; b=dCBXHXbjGoBpIhGoXGZ7iKkBIEHhAgHgXXu5HIjCghZSAypCytbSQX268Pqm5k289KlTb7 8QvwqdrQ5UvfM23F//DrChgQ3ufM3rKwKRe3ZqYh+HcWJJ2gLVDv0eo8zYcVuV+aXgqpCb J53k80e4ZE8Nik/Hf5kUE3sjtFmhrpM= 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-527-6la-ZXceMxmDj_vji3ckbg-1; Tue, 19 Sep 2023 13:30:41 -0400 X-MC-Unique: 6la-ZXceMxmDj_vji3ckbg-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (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 56FA6805B29; Tue, 19 Sep 2023 17:30:40 +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 BFAD4400F12; Tue, 19 Sep 2023 17:30:39 +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 1B7BB19465B8; Tue, 19 Sep 2023 17:30:18 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 157161946594 for ; Tue, 19 Sep 2023 16:40:33 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id E4B4C2156702; Tue, 19 Sep 2023 16:40:27 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast01.extmail.prod.ext.rdu2.redhat.com [10.11.55.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DDC9E2156701 for ; Tue, 19 Sep 2023 16:40:27 +0000 (UTC) Received: from us-smtp-inbound-delivery-1.mimecast.com (us-smtp-inbound-delivery-1.mimecast.com [207.211.31.81]) (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 BE45B858F1C for ; Tue, 19 Sep 2023 16:40:27 +0000 (UTC) Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-425-Saf5bi8JNGKlGnrL4UjUPw-1; Tue, 19 Sep 2023 12:40:23 -0400 X-MC-Unique: Saf5bi8JNGKlGnrL4UjUPw-1 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 8CD0BCE139A; Tue, 19 Sep 2023 16:31:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 07A27C433CD; Tue, 19 Sep 2023 16:31:09 +0000 (UTC) Message-ID: <08b5c6fd3b08b87fa564bb562d89381dd4e05b6a.camel@kernel.org> From: Jeff Layton To: Bruno Haible , Jan Kara , Xi Ruoyao , bug-gnulib@gnu.org Date: Tue, 19 Sep 2023 12:31:08 -0400 In-Reply-To: <4511209.uG2h0Jr0uP@nimes> References: <20230807-mgctime-v7-0-d1dec143a704@kernel.org> <20230919110457.7fnmzo4nqsi43yqq@quack3> <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> <4511209.uG2h0Jr0uP@nimes> User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 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.6 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 , 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 , Amir Goldstein , Eric Van Hensbergen , Miklos Szeredi , Richard Weinberger , Mark Fasheh , Hugh Dickins , Tyler Hicks , cluster-devel@redhat.com, coda@cs.cmu.edu, linux-mm@kvack.org, Ilya Dryomov , Iurii Zaikin , Namjae Jeon , Trond Myklebust , Shyam Prasad N , ecryptfs@vger.kernel.org, Kees Cook , ocfs2-devel@lists.linux.dev, linux-cifs@vger.kernel.org, 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.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: kernel.org Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable On Tue, 2023-09-19 at 16:52 +0200, Bruno Haible wrote: > 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. >=20 > This is only of secondary importance, because the scenario by Jan Kara > shows a much more fundamental breakage: >=20 > > > The ultimate problem is that a sequence like: > > >=20 > > > write(f1) > > > stat(f2) > > > write(f2) > > > stat(f2) > > > write(f1) > > > stat(f1) > > >=20 > > > 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 com= pare > > > timestamps between two files. Jeff? > > >=20 > >=20 > > Basically yes. >=20 > f1 was last written to *after* f2 was last written to. If the timestamp o= f f1 > is then lower than the timestamp of f2, timestamps are fundamentally brok= en. >=20 > Many things in user-space depend on timestamps, such as build system > centered around 'make', but also 'find ... -newer ...'. >=20 What does breakage with make look like in this situation? The "fuzz" here is going to be on the order of a jiffy. The typical case for make timestamp comparisons is comparing source files vs. a build target. If those are being written nearly simultaneously, then that could be an issue, but is that a typical behavior? It seems like it would be hard to rely on that anyway, esp. given filesystems like NFS that can do lazy writeback. One of the operating principles with this series is that timestamps can be of varying granularity between different files. Note that Linux already violates this assumption when you're working across filesystems of different types. As to potential fixes if this is a real problem: I don't really want to put this behind a mount or mkfs option (a'la relatime, etc.), but that is one possibility. I wonder if it would be feasible to just advance the coarse-grained current_time whenever we end up updating a ctime with a fine-grained timestamp? It might produce some inode write amplification. Files that were written within the same jiffy could see more inode transactions logged, but that still might not be _too_ awful. I'll keep thinking about it for now. --=20 Jeff Layton