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 5E11ECD54B5 for ; Tue, 19 Sep 2023 11:44:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695123893; 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=3M0d3dD3pzePraPqdY5Lb/FSgSUINN1vw73+jr5dq7Q=; b=Gxaed6+FmQJyMnWUHGhWV0MurCgnN9/a0VbG76Ow2r0BhVa0C8jpOb54gBglhlb2V7rm94 AQmD2R+n7iUJBcRfKVhfWaBo6teLuOAC0sIHtSHr6LhBDXC3B9pNCIJX5fwhD80dDnyeec hXOnq6AUfhdNHPsKrGEcwcpWY/d1tvQ= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-653-_87pC9I0PKqNe9HOmyxsmw-1; Tue, 19 Sep 2023 07:44:50 -0400 X-MC-Unique: _87pC9I0PKqNe9HOmyxsmw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (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 8A9F83C11A08; Tue, 19 Sep 2023 11:44:49 +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 44D542904; Tue, 19 Sep 2023 11:44:49 +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 E5FAB194658D; Tue, 19 Sep 2023 11:44:48 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id A3F21194658C for ; Tue, 19 Sep 2023 11:44:41 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 807D21005E27; Tue, 19 Sep 2023 11:44:41 +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 78B881006B72 for ; Tue, 19 Sep 2023 11:44:41 +0000 (UTC) Received: from us-smtp-inbound-delivery-1.mimecast.com (us-smtp-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 55C8E85A5A8 for ; Tue, 19 Sep 2023 11:44:41 +0000 (UTC) Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-311-enpOYROMO7SMh64H3UWZKg-1; Tue, 19 Sep 2023 07:44:37 -0400 X-MC-Unique: enpOYROMO7SMh64H3UWZKg-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 ams.source.kernel.org (Postfix) with ESMTPS id D45C8B815DD; Tue, 19 Sep 2023 11:33:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D159EC433C8; Tue, 19 Sep 2023 11:33:26 +0000 (UTC) Message-ID: <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> From: Jeff Layton To: Jan Kara , Xi Ruoyao Date: Tue, 19 Sep 2023 07:33:25 -0400 In-Reply-To: <20230919110457.7fnmzo4nqsi43yqq@quack3> References: <20230807-mgctime-v7-0-d1dec143a704@kernel.org> <20230807-mgctime-v7-12-d1dec143a704@kernel.org> <20230919110457.7fnmzo4nqsi43yqq@quack3> 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.3 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, 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.5 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 13:04 +0200, Jan Kara wrote: > On Tue 19-09-23 15:05:24, Xi Ruoyao wrote: > > On Mon, 2023-08-07 at 15:38 -0400, Jeff Layton wrote: > > > Enable multigrain timestamps, which should ensure that there is an > > > apparent change to the timestamp whenever it has been written after > > > being actively observed via getattr. > > >=20 > > > For ext4, we only need to enable the FS_MGTIME flag. > >=20 > > Hi Jeff, > >=20 > > This patch causes a gnulib test failure: > >=20 > > $ ~/sources/lfs/grep-3.11/gnulib-tests/test-stat-time > > test-stat-time.c:141: assertion 'statinfo[0].st_mtime < statinfo[2].st_= mtime || (statinfo[0].st_mtime =3D=3D statinfo[2].st_mtime && (get_stat_mti= me_ns (&statinfo[0]) < get_stat_mtime_ns (&statinfo[2])))' failed > > Aborted (core dumped) > >=20 > > The source code of the test: > > https://git.savannah.gnu.org/cgit/gnulib.git/tree/tests/test-stat-time.= c > >=20 > > Is this an expected change? >=20 > Kind of yes. The test first tries to estimate filesystem timestamp > granularity in nap() function - due to this patch, the detected granulari= ty > will likely be 1 ns so effectively all the test calls will happen > immediately one after another. But we don't bother setting the timestamps > with more than 1 jiffy (usually 4 ms) precision unless we think someone i= s > watching. So as a result timestamps of all stamp1 and stamp2 files are > going to be equal which makes the test fail. >=20 That was my take too. The multigrain ctime changes are probably causing nap() to settle on too small a time delta. > The ultimate problem is that a sequence like: >=20 > 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? >=20 Basically yes. When there is no stat() call issued on the file in between writes, the kernel will use coarse-grained timestamps when updating it (since no one is watching). 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 Jeff Layton