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 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 2E582CE79CF for ; Wed, 20 Sep 2023 12:49:46 +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=O12Jm8Bs; 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=muQUVTl0; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4RrJJm5klCz3c1L for ; Wed, 20 Sep 2023 22:49:44 +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=O12Jm8Bs; dkim=pass header.d=clisp.org header.i=@clisp.org header.a=ed25519-sha256 header.s=strato-dkim-0003 header.b=muQUVTl0; 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.174; helo=mo4-p03-ob.smtp.rzone.de; envelope-from=bruno@clisp.org; receiver=lists.ozlabs.org) Received: from mo4-p03-ob.smtp.rzone.de (mo4-p03-ob.smtp.rzone.de [81.169.146.174]) (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 4RrJJc3PkMz3byH for ; Wed, 20 Sep 2023 22:49:34 +1000 (AEST) ARC-Seal: i=1; a=rsa-sha256; t=1695214142; cv=none; d=strato.com; s=strato-dkim-0002; b=KK4wxmcg11bDhbWnUFC83uZ811y/mpb0I1TmJbK4Xk4jnQh4eSC/Y+vtwGlPKLxw9f ZQJV08gwelI0hs7Nko3i2MdGYFFoM9tT1tP4c6kr2+FD/bMZ5Us4S1IamSJP7z2u2Tni VGrvJR9cFI9cNWYNVXlV4wEMgQPoFUsGO26ode4TY1Iyrfpxra0unC1MrVpv8ibEB9+j zFGTjBklu569rK9lelqLmPbUbCvydW08SWCBN0VIPOuJD6DxdrrJwE7b+oQvIZvbb2gB gvGEBEb/Y1uiuRnorDANT4ornmti5i01W1zbKwyhST0ousOicmaYHuksmnMxb6uUQJSc GcjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1695214142; 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=zlon1NnZN5jZFLvNv3xx2YjDrrfzc/zzmMPbj7gP0jk=; b=d2z+l5GTzEzeupyyKoEO/+801nRO2I8xrBbgDMbJ0FszbQsZ7OWKerKKY869DbFMSr DA55dD3c8Iy22q32azarKo9LmVUAE/wwLMEkbofjeQtY2NHv5KyEQ5lCwDIcZj6/Dssl rR06w99QqJPCaVp01TF7Yn083P4ftn6AoEorFHVtk+giqDT7I9UeWxfbrgljCBX0K9NB 27KHTBXszEyKAusPHW96Eg39CS+TryRIAsU+dqtvvDkSuODIRZZtwIQ1GsA7NETvfjHn VcnTxIDslnv+v3qX0yKYPfHAa3QFZGq2mRblvL54+mqYfwy9M1pc+w1udoTKxkxma9Q+ sJBw== 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=1695214142; 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=zlon1NnZN5jZFLvNv3xx2YjDrrfzc/zzmMPbj7gP0jk=; b=O12Jm8BsjyLsoq3xcyYi16mtuh91ZCa5znbPcUnLqZstPIUAkcvAVtfQJ5y2yLTnkG Bbd1Vjx8o91hiawH0LIwFIUvSMwyAjpO+JZjkt3g+Qpq83IYi33H61+PZsHsDjUPV+gY 5VkfMVdagu9bFaEq9tpHPC8aYSffOTVdZHc9t/Mr9BI62tRv6l/vCIVCxLdoBqlXpQ01 P1/x918UXZr3OP5PUsCgWe+NPzvAlgR7TOhOMxOk5E0RnLfQmpNp6vkh2VWa4G4mfKF1 8rEFhafAogS/DwPxgDZRaiLuEskuztanzAxVYeOjpAoKDywwLsnNuTQKZWxS/0d3sF8x RUJQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1695214142; 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=zlon1NnZN5jZFLvNv3xx2YjDrrfzc/zzmMPbj7gP0jk=; b=muQUVTl0scIb2+N29B0TOhmsUwAw8Fpx6zlqzw9owQDn3QGFXl2h7ouqcgMeKa+h7z NeiR9RifaRHNd7IhFiCQ== 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 Subject: Re: [PATCH v7 12/13] ext4: switch to multigrain timestamps 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 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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 , 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 , bug-gnulib@gnu.org, Andreas Gruenbacher , Miklos Szeredi , Richard Weinberger , Mark Fasheh , Hugh Dickins , Benjamin Coddington , Tyl er Hicks , cluster-devel@redhat.com, coda@cs.cmu.edu, linux-mm@kvack.org, 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, 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 Kroa h-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 , Bo b Peterson , linux-fsdevel@vger.kernel.org, Andrew Morton , Sungjong Seo , linux-erofs@lists.ozlabs.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: > > 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. =46or 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 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 75529CE79CF for ; Wed, 20 Sep 2023 12:49:59 +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=RBwfmLcITtboSt6SVxDFN9Y1gWwDR+s2O6aQyXxgn+A=; b=padbEeC1LkA2Gj a0hQmqjqPzAkpeGCcEzMMUnytHkFW+FwIyRCfwKMinQUD5ZjbpAQgsnSKprfFHl/vdglpX95Xy840 dNIDk4JxnRPYUJ87ojMa6RKdk2rpEkyBaIfwr7DHG7ecg0sz4hQrs6rWqpK7C1W7bQMgmVNNrHozR Bp7AN4gOs3yn2NkWWY0cqLBXjxPNDaGrQIofzNhLr8RK4BtbA3UNxOsL+5yF5fSC8jFpAPAQbL5i8 nszGlMb56QI6D2F0tuotubAURAF0uLp7xasPBsRSJXs9ofn19dZA09Y4qakw8gKHInECD3k9Yw/jG e5SM39XV2wluPl+yM7lQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qiweK-0035Rw-1Z; Wed, 20 Sep 2023 12:49:48 +0000 Received: from mo4-p03-ob.smtp.rzone.de ([81.169.146.175]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qiweH-0035Qd-0F; Wed, 20 Sep 2023 12:49:46 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1695214142; cv=none; d=strato.com; s=strato-dkim-0002; b=KK4wxmcg11bDhbWnUFC83uZ811y/mpb0I1TmJbK4Xk4jnQh4eSC/Y+vtwGlPKLxw9f ZQJV08gwelI0hs7Nko3i2MdGYFFoM9tT1tP4c6kr2+FD/bMZ5Us4S1IamSJP7z2u2Tni VGrvJR9cFI9cNWYNVXlV4wEMgQPoFUsGO26ode4TY1Iyrfpxra0unC1MrVpv8ibEB9+j zFGTjBklu569rK9lelqLmPbUbCvydW08SWCBN0VIPOuJD6DxdrrJwE7b+oQvIZvbb2gB gvGEBEb/Y1uiuRnorDANT4ornmti5i01W1zbKwyhST0ousOicmaYHuksmnMxb6uUQJSc GcjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1695214142; 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=zlon1NnZN5jZFLvNv3xx2YjDrrfzc/zzmMPbj7gP0jk=; b=d2z+l5GTzEzeupyyKoEO/+801nRO2I8xrBbgDMbJ0FszbQsZ7OWKerKKY869DbFMSr DA55dD3c8Iy22q32azarKo9LmVUAE/wwLMEkbofjeQtY2NHv5KyEQ5lCwDIcZj6/Dssl rR06w99QqJPCaVp01TF7Yn083P4ftn6AoEorFHVtk+giqDT7I9UeWxfbrgljCBX0K9NB 27KHTBXszEyKAusPHW96Eg39CS+TryRIAsU+dqtvvDkSuODIRZZtwIQ1GsA7NETvfjHn VcnTxIDslnv+v3qX0yKYPfHAa3QFZGq2mRblvL54+mqYfwy9M1pc+w1udoTKxkxma9Q+ sJBw== 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=1695214142; 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=zlon1NnZN5jZFLvNv3xx2YjDrrfzc/zzmMPbj7gP0jk=; b=O12Jm8BsjyLsoq3xcyYi16mtuh91ZCa5znbPcUnLqZstPIUAkcvAVtfQJ5y2yLTnkG Bbd1Vjx8o91hiawH0LIwFIUvSMwyAjpO+JZjkt3g+Qpq83IYi33H61+PZsHsDjUPV+gY 5VkfMVdagu9bFaEq9tpHPC8aYSffOTVdZHc9t/Mr9BI62tRv6l/vCIVCxLdoBqlXpQ01 P1/x918UXZr3OP5PUsCgWe+NPzvAlgR7TOhOMxOk5E0RnLfQmpNp6vkh2VWa4G4mfKF1 8rEFhafAogS/DwPxgDZRaiLuEskuztanzAxVYeOjpAoKDywwLsnNuTQKZWxS/0d3sF8x RUJQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1695214142; 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=zlon1NnZN5jZFLvNv3xx2YjDrrfzc/zzmMPbj7gP0jk=; b=muQUVTl0scIb2+N29B0TOhmsUwAw8Fpx6zlqzw9owQDn3QGFXl2h7ouqcgMeKa+h7z NeiR9RifaRHNd7IhFiCQ== 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 Cc: Xi Ruoyao , bug-gnulib@gnu.org, Alexander Viro , 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 , "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 Subject: Re: [PATCH v7 12/13] ext4: switch to multigrain timestamps 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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230920_054945_261348_752D895B X-CRM114-Status: GOOD ( 15.27 ) 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="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org SmVmZiBMYXl0b24gd3JvdGU6Cj4gPiBTdXJlbHkgdGhpcyBpcyBhIHNhZmUgY2hvaWNlIGFzIGl0 IG1vdmVzIHRoZSByZXNwb25zaWJpbGl0eSB0byB0aGUgc3lzYWRtaW4KPiA+IGFuZCB0aGUgY2Fz ZXMgd2hlcmUgZmluZWdyYWluZWQgdGltZXN0YW1wcyBhcmUgcmVxdWlyZWQuIEJ1dCBJIGtpbmQg b2YKPiA+IHdvbmRlciBob3cgaXMgdGhlIHN5c2FkbWluIGdvaW5nIHRvIGRlY2lkZSB3aGV0aGVy IG1ndGltZSBpcyBzYWZlIGZvciBoaXMKPiA+IHN5c3RlbSBvciBub3Q/IEJlY2F1c2UgdGhlIHBv c3NpYmxlIGJyZWFrYWdlIG5lZWRuJ3QgYmUgb2J2aW91cyBhdCB0aGUKPiA+IGZpcnN0IHNpZ2h0 Li4uCj4gCj4gVGhhdCdzIHRoZSBtYWluIHJlYXNvbiBJIHJlYWxseSBkaWRuJ3Qgd2FudCB0byBn byB3aXRoIGEgbW91bnQgb3B0aW9uLgo+IERvY3VtZW50aW5nIHRoYXQgbWF5IGJlIGRpZmZpY3Vs dC4KCllvdSBjb3VsZCBkb2N1bWVudCBpdCBsaWtlIHRoaXM6CgogIFRoZSBtZ3RpbWUgb3B0aW9u IGVuYWJsZXMgbW9yZSBwcmVjaXNlIG1vZGlmaWNhdGlvbiB0aW1lcyAobXRpbWUpCiAgb24gc29t ZSBmaWxlcywgdG9nZXRoZXIgd2l0aCBhbiBvcHRpbWl6YXRpb24gdGhhdCBsaW1pdHMgdGhlIGFt b3VudAogIG9mIG1ldGFkYXRhIGNoYW5nZXMuCiAgTm90ZSB0aGF0IHRoaXMgb3B0aW9uIG1heSwg aW4gc29tZSBjYXNlcywgYWZ0ZXIgd3JpdGluZyB0byBmaWxlIEYxCiAgYW5kIHRoZW4gd3JpdGlu ZyB0byBmaWxlIEYyLCByZXBvcnQgYSBsb3dlciBtdGltZSBmb3IgRjIgdGhhbiBmb3IgRjIuCiAg RW5hYmxpbmcgdGhpcyBvcHRpb24gbWF5IGJlIHVzZWZ1bCBvbiBmaWxlIHN5c3RlbXMgc2hhcmVk IHZpYSBORlMuCiAgVGhlIHNhZmUgY2hvaWNlIGlzIHRvIGRpc2FibGUgdGhpcyBvcHRpb24uCgpG b3IgbWUgYXMgYSB1c2VyLCB0aGVyZSdzIG5vIG5lZWQgdG8gZ28gaW50byBtb3JlIGRldGFpbHMg dGhhbiB0aGF0LgoKSXQncyBpbXBvcnRhbnQgdG8gaGF2ZSB0aGlzIG1vdW50IG9wdGlvbiwgZm9y IHBlb3BsZSB3aG8gd2FudCBtYXhpbXVtCnJlbGlhYmlsaXR5LiBQZXJzb25hbGx5LCBJIGFsd2F5 cyBlbmFibGUgdGhlICdzdHJpY3RhdGltZScgb3B0aW9uIG9uCmFsbCBleHQ0IG1vdW50cywgc2lu Y2UgJ3JlbGF0aW1lJyBvcHRpbWl6ZXMgdG9vIG11Y2ggZm9yIG15IHVzZS1jYXNlcy4KSWYgSSBm ZWFyIHdyb25nIHJlc3VsdHMgb2YgIm1ha2UiIHJ1bnMsIEkgd2lsbCBkZWZpbml0ZWx5IG9wdCBm b3IgdGhlCnNhZmUgY2hvaWNlIHJlZ2FyZGluZyBtZ3RpbWUgYXMgd2VsbCDigJQgc2luY2UgSSBk b24ndCB3YW50IHRvIHNwZW5kCmhvdXJzIGRlYnVnZ2luZyBiaW5hcmllcyB0aGF0IHdlcmUgYnVp bHQgaW5jb3JyZWN0bHkgZnJvbSBjb3JyZWN0CnNvdXJjZSBjb2RlLgoKQnJ1bm8KCgoKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpMaW51eCBN VEQgZGlzY3Vzc2lvbiBtYWlsaW5nIGxpc3QKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFp bG1hbi9saXN0aW5mby9saW51eC1tdGQvCg== 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 E2AF631A68; Wed, 20 Sep 2023 13:01:05 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1695214142; cv=none; d=strato.com; s=strato-dkim-0002; b=KK4wxmcg11bDhbWnUFC83uZ811y/mpb0I1TmJbK4Xk4jnQh4eSC/Y+vtwGlPKLxw9f ZQJV08gwelI0hs7Nko3i2MdGYFFoM9tT1tP4c6kr2+FD/bMZ5Us4S1IamSJP7z2u2Tni VGrvJR9cFI9cNWYNVXlV4wEMgQPoFUsGO26ode4TY1Iyrfpxra0unC1MrVpv8ibEB9+j zFGTjBklu569rK9lelqLmPbUbCvydW08SWCBN0VIPOuJD6DxdrrJwE7b+oQvIZvbb2gB gvGEBEb/Y1uiuRnorDANT4ornmti5i01W1zbKwyhST0ousOicmaYHuksmnMxb6uUQJSc GcjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1695214142; 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=zlon1NnZN5jZFLvNv3xx2YjDrrfzc/zzmMPbj7gP0jk=; b=d2z+l5GTzEzeupyyKoEO/+801nRO2I8xrBbgDMbJ0FszbQsZ7OWKerKKY869DbFMSr DA55dD3c8Iy22q32azarKo9LmVUAE/wwLMEkbofjeQtY2NHv5KyEQ5lCwDIcZj6/Dssl rR06w99QqJPCaVp01TF7Yn083P4ftn6AoEorFHVtk+giqDT7I9UeWxfbrgljCBX0K9NB 27KHTBXszEyKAusPHW96Eg39CS+TryRIAsU+dqtvvDkSuODIRZZtwIQ1GsA7NETvfjHn VcnTxIDslnv+v3qX0yKYPfHAa3QFZGq2mRblvL54+mqYfwy9M1pc+w1udoTKxkxma9Q+ sJBw== 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=1695214142; 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=zlon1NnZN5jZFLvNv3xx2YjDrrfzc/zzmMPbj7gP0jk=; b=O12Jm8BsjyLsoq3xcyYi16mtuh91ZCa5znbPcUnLqZstPIUAkcvAVtfQJ5y2yLTnkG Bbd1Vjx8o91hiawH0LIwFIUvSMwyAjpO+JZjkt3g+Qpq83IYi33H61+PZsHsDjUPV+gY 5VkfMVdagu9bFaEq9tpHPC8aYSffOTVdZHc9t/Mr9BI62tRv6l/vCIVCxLdoBqlXpQ01 P1/x918UXZr3OP5PUsCgWe+NPzvAlgR7TOhOMxOk5E0RnLfQmpNp6vkh2VWa4G4mfKF1 8rEFhafAogS/DwPxgDZRaiLuEskuztanzAxVYeOjpAoKDywwLsnNuTQKZWxS/0d3sF8x RUJQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1695214142; 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=zlon1NnZN5jZFLvNv3xx2YjDrrfzc/zzmMPbj7gP0jk=; b=muQUVTl0scIb2+N29B0TOhmsUwAw8Fpx6zlqzw9owQDn3QGFXl2h7ouqcgMeKa+h7z NeiR9RifaRHNd7IhFiCQ== 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 Cc: Xi Ruoyao , bug-gnulib@gnu.org, Alexander Viro , 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 , "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 Subject: Re: [PATCH v7 12/13] ext4: switch to multigrain timestamps 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> Precedence: bulk X-Mailing-List: ntfs3@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 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. =46or 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 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 5BC28CE79CE for ; Wed, 20 Sep 2023 12:49:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E26396B0153; Wed, 20 Sep 2023 08:49:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DD6CC6B0154; Wed, 20 Sep 2023 08:49:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C77786B0155; Wed, 20 Sep 2023 08:49:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B827A6B0153 for ; Wed, 20 Sep 2023 08:49:12 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 9311CA04F7 for ; Wed, 20 Sep 2023 12:49:12 +0000 (UTC) X-FDA: 81256956144.05.B514B6A Received: from mo4-p03-ob.smtp.rzone.de (mo4-p03-ob.smtp.rzone.de [85.215.255.103]) by imf03.hostedemail.com (Postfix) with ESMTP id 5FEDB20013 for ; Wed, 20 Sep 2023 12:49:10 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=clisp.org header.s=strato-dkim-0002 header.b=O12Jm8Bs; dkim=pass header.d=clisp.org header.s=strato-dkim-0003 header.b=muQUVTl0; spf=none (imf03.hostedemail.com: domain of bruno@clisp.org has no SPF policy when checking 85.215.255.103) smtp.mailfrom=bruno@clisp.org; dmarc=none; arc=pass ("strato.com:s=strato-dkim-0002:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695214150; 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=zlon1NnZN5jZFLvNv3xx2YjDrrfzc/zzmMPbj7gP0jk=; b=u5z96SHF1TFr8UQ7Z3bEGLWhrwC+xyqpxrnn8csoKhF+ujZHW3MioIK4NlDIG/IcF4584s w4O+4bfLYPN4cXA8DnsaklSfA0wReRRavqgn+kjV6GDazFWqMs6TsMiM4OtUDeDEJHII8H JnAklQidfRaAMlEeR3Xb9//ORFI5AHY= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1695214150; a=rsa-sha256; cv=pass; b=YqubdmoIylmgC9VcRDwzHkxYXlSUvZOFnq1iPkJzEwGwLvUgY1GlGatk3SjoRWwl3Go5o8 ydieVTleOJimmShkNqAAp5JJITyk5waZhsDifBQE7oKleO7A3VhLHiZZNlyJDj9OTK0vHX 4tVayN6mePD/HTIUBaEHO61Ulal+upY= ARC-Authentication-Results: i=2; imf03.hostedemail.com; dkim=pass header.d=clisp.org header.s=strato-dkim-0002 header.b=O12Jm8Bs; dkim=pass header.d=clisp.org header.s=strato-dkim-0003 header.b=muQUVTl0; spf=none (imf03.hostedemail.com: domain of bruno@clisp.org has no SPF policy when checking 85.215.255.103) smtp.mailfrom=bruno@clisp.org; dmarc=none; arc=pass ("strato.com:s=strato-dkim-0002:i=1") ARC-Seal: i=1; a=rsa-sha256; t=1695214142; cv=none; d=strato.com; s=strato-dkim-0002; b=KK4wxmcg11bDhbWnUFC83uZ811y/mpb0I1TmJbK4Xk4jnQh4eSC/Y+vtwGlPKLxw9f ZQJV08gwelI0hs7Nko3i2MdGYFFoM9tT1tP4c6kr2+FD/bMZ5Us4S1IamSJP7z2u2Tni VGrvJR9cFI9cNWYNVXlV4wEMgQPoFUsGO26ode4TY1Iyrfpxra0unC1MrVpv8ibEB9+j zFGTjBklu569rK9lelqLmPbUbCvydW08SWCBN0VIPOuJD6DxdrrJwE7b+oQvIZvbb2gB gvGEBEb/Y1uiuRnorDANT4ornmti5i01W1zbKwyhST0ousOicmaYHuksmnMxb6uUQJSc GcjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1695214142; 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=zlon1NnZN5jZFLvNv3xx2YjDrrfzc/zzmMPbj7gP0jk=; b=d2z+l5GTzEzeupyyKoEO/+801nRO2I8xrBbgDMbJ0FszbQsZ7OWKerKKY869DbFMSr DA55dD3c8Iy22q32azarKo9LmVUAE/wwLMEkbofjeQtY2NHv5KyEQ5lCwDIcZj6/Dssl rR06w99QqJPCaVp01TF7Yn083P4ftn6AoEorFHVtk+giqDT7I9UeWxfbrgljCBX0K9NB 27KHTBXszEyKAusPHW96Eg39CS+TryRIAsU+dqtvvDkSuODIRZZtwIQ1GsA7NETvfjHn VcnTxIDslnv+v3qX0yKYPfHAa3QFZGq2mRblvL54+mqYfwy9M1pc+w1udoTKxkxma9Q+ sJBw== 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=1695214142; 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=zlon1NnZN5jZFLvNv3xx2YjDrrfzc/zzmMPbj7gP0jk=; b=O12Jm8BsjyLsoq3xcyYi16mtuh91ZCa5znbPcUnLqZstPIUAkcvAVtfQJ5y2yLTnkG Bbd1Vjx8o91hiawH0LIwFIUvSMwyAjpO+JZjkt3g+Qpq83IYi33H61+PZsHsDjUPV+gY 5VkfMVdagu9bFaEq9tpHPC8aYSffOTVdZHc9t/Mr9BI62tRv6l/vCIVCxLdoBqlXpQ01 P1/x918UXZr3OP5PUsCgWe+NPzvAlgR7TOhOMxOk5E0RnLfQmpNp6vkh2VWa4G4mfKF1 8rEFhafAogS/DwPxgDZRaiLuEskuztanzAxVYeOjpAoKDywwLsnNuTQKZWxS/0d3sF8x RUJQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1695214142; 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=zlon1NnZN5jZFLvNv3xx2YjDrrfzc/zzmMPbj7gP0jk=; b=muQUVTl0scIb2+N29B0TOhmsUwAw8Fpx6zlqzw9owQDn3QGFXl2h7ouqcgMeKa+h7z NeiR9RifaRHNd7IhFiCQ== 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 Cc: Xi Ruoyao , bug-gnulib@gnu.org, Alexander Viro , 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 <"m iklos"@szeredi.hu>, 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 , A mir 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 Subject: Re: [PATCH v7 12/13] ext4: switch to multigrain timestamps 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 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 5FEDB20013 X-Rspam-User: X-Stat-Signature: 4qkfh6j68yjwui7gpjcp4maa4cd1znu1 X-Rspamd-Server: rspam03 X-HE-Tag: 1695214150-58795 X-HE-Meta: U2FsdGVkX1/mfoz5w3tEFR2z5KuJSUmfm/b+B/1AExMUpQGELG2E/1r+NTRNk39QZK2HzIvluNhnVnodlX1yD6Lk0lMUNoRw1fYuXjmiyuxgcmtNREQwwpdd/AlyD5oVscq2dB7QgK2yXcdbsTWWcHapfuWuW35IH6ej7eOjljEg8mhx8YF3NUntY5hZp3NisXohyIT4mSFqFEP3BFBCV4krATwpmBW5zOA7hmaUKgvNRpK2t7utnbuw6uOIbEJP4PUyjg9Ox61qxfwL0vqSK8Vhqrq1C8eFGN3LS3uUbelEW+qKk3iPyOKIO5UM4GHmMI45I5zaD05CmVteIF9gPIHrXi/R77+XAz2A7YKdA54LXr/n5x99cTwa6s4OE52dDwEhS0e2tF6vE92iwfH4lRaoYQZQOe7anOTV2+nIGKduNmahq/mQJzoyzZhXTnrYm/hcCRzRgz/OfHDi/FM3oLWTZIO6aSlppSmS1k8sa1TIQvPwd2Cf6ix1OY/gc+B6iU/6gyNeG829mXx9zC+bQ5ef39KE6ey4L0etIM92a1iGNi3mc3KuSIqKbOo9bHrkfyT8F/a5Y6jBAb9KD6TOEz0zhODF39biDfLGxa+Mabqn/WTrhvvFQtbyw313dU2jVQ6QY5oJMnJ9tS3Lgwqx5jRxMEsDtUFb3KOS/KzOQ/O5DE9kOpPG+w33CQosfhoyZOw5GL5l0THUgvIlu/fOl9l1hBQWcJpUOu05Fgz5Bq/uH6F6nDhpzLi05u6MHU66kd8lEX5TFJ0qUZbHPdRhI4UKw1tNOs3j7R3hG7icmOCdNJybBfDSSsbPXZo5aPsjoYGE5lNWi6vS6Wgr2FKHupfHyz6fD2JPFIZy3exaKgMNHe2+RdYKR7hT6WV4MdTqdWv/dubSQOgINnR3lXUhj32Gf2dmXMkhw4AyJPDfgPITzDFTwDBtVDSPGwV7t2ssnRsckEIluor6oMkMDYM ACpbjojC Z8I3KRgk/zCwntWmqBGxLmgVZX8jG9/uRbTUi0lc+Ann4akce1/676OEv1x9EILBAzbngrJQy2YUdk+K3u9guN1hPLof8hhfaKBiPfhlV4IIHDhDdb58G8AlGB37Gxa2t9ebYyAoDXu5ZToseA905bRyuVF1Ylve7SauhZM8QgYprPxj8J5L5cRzB63e6uO6i3JWLHVXPIWkjyXQ= 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: > > 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. =46or 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