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 112D8CE79D1 for ; Wed, 20 Sep 2023 13:51:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695217880; 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=UNz4iRx1r4KLmByJgz2DZIEVlISmUQYul/QUmIW94Ns=; b=FXX/7x8qKkUf2aXjspSbVUCIynF4rLMhIM/WoYvkQ7j6YqR2iuFpmIXj5DY9yHUUhhi81t shZAUDt+7GeiyQMnAws5EqaZ2Qmit5AXu220cpGLz43LDiNWpVdXuO3u6OWdn8m+EQggSo IDQRDOfFdtiCh59pM65NV0rtg0oHQ2U= 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-582-5bjR0axNOQWaAs4tjidL-g-1; Wed, 20 Sep 2023 09:51:16 -0400 X-MC-Unique: 5bjR0axNOQWaAs4tjidL-g-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 BC8D7101B040; Wed, 20 Sep 2023 13:51:15 +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 90A1640C2064; Wed, 20 Sep 2023 13:51: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 6B68319465B8; Wed, 20 Sep 2023 13:51:10 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 14EDE194658D for ; Wed, 20 Sep 2023 12:52:09 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id DA79320268CC; Wed, 20 Sep 2023 12:52:03 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast07.extmail.prod.ext.rdu2.redhat.com [10.11.55.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D24B7202696C for ; Wed, 20 Sep 2023 12:52:03 +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 A56F63C1ACE7 for ; Wed, 20 Sep 2023 12:52:03 +0000 (UTC) Received: from mo4-p03-ob.smtp.rzone.de (mo4-p03-ob.smtp.rzone.de [81.169.146.175]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-222-LXaOy8aJNceU7pG2ln4q3w-1; Wed, 20 Sep 2023 08:52:01 -0400 X-MC-Unique: LXaOy8aJNceU7pG2ln4q3w-1 X-RZG-CLASS-ID: mo03 X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPHj6eWWaUQFt689wZebbvySt9BLA==" Received: from nimes.localnet by smtp.strato.de (RZmta 49.8.2 AUTH) with ESMTPSA id m03934z8KCmwmFD (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Wed, 20 Sep 2023 14:48:58 +0200 (CEST) From: Bruno Haible To: Jan Kara , Christian Brauner , Jeff Layton Date: Wed, 20 Sep 2023 14:48:57 +0200 Message-ID: <5317021.Rkz2Fa4CmG@nimes> In-Reply-To: <317d84b1b909b6c6519a2406fcb302ce22dafa41.camel@kernel.org> References: <20230807-mgctime-v7-0-d1dec143a704@kernel.org> <20230920101731.ym6pahcvkl57guto@quack3> <317d84b1b909b6c6519a2406fcb302ce22dafa41.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.4 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 , A mir Goldstein , 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, Gao Xiang , Iurii Zaikin , Namjae Jeon , Trond Myklebust , Xi Ruoyao , 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 , Ilya Dryomov , OGAWA Hirofumi , Jan Harkes , linux-nfs@vger.kernel.org, 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-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: quoted-printable Content-Type: text/plain; charset="UTF-8" Jeff Layton wrote: > > Surely this is a safe choice as it moves the responsibility to the sysa= dmin > > and the cases where finegrained timestamps are required. But I kind of > > wonder how is the sysadmin going to decide whether mgtime is safe for h= is > > system or not? Because the possible breakage needn't be obvious at the > > first sight... >=20 > That's the main reason I really didn't want to go with a mount option. > Documenting that may be difficult. You could document it like this: The mgtime option enables more precise modification times (mtime) on some files, together with an optimization that limits the amount of metadata changes. Note that this option may, in some cases, after writing to file F1 and then writing to file F2, report a lower mtime for F2 than for F2. Enabling this option may be useful on file systems shared via NFS. The safe choice is to disable this option. For me as a user, there's no need to go into more details than that. It's important to have this mount option, for people who want maximum reliability. Personally, I always enable the 'strictatime' option on all ext4 mounts, since 'relatime' optimizes too much for my use-cases. If I fear wrong results of "make" runs, I will definitely opt for the safe choice regarding mgtime as well =E2=80=94 since I don't want to spend hours debugging binaries that were built incorrectly from correct source code. Bruno