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 B45D0C001B0 for ; Wed, 9 Aug 2023 16:31:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1691598683; 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=evh/QnTRbtms70P8fyMuk+3Fiu52AhvsRjN/d0cOnmg=; b=gxH75gRCqjdIA0Ifz3L9lrSpkH3WgmocsaYtAUDj/Xa3tp68tfGtjRv4nT+VopYzIZn7BM fCKdma4P4szOku42rTwwe5tRHucGdzQG82KKxM9VqyftIG9w9gwRbGoIOQFIVAk1XxxnlQ cviKh8S1wQzwwGezrPm+9Isu3bV+6tc= Received: from mimecast-mx02.redhat.com (66.187.233.73 [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-rhF_x51xNMSwv34nrQ4lig-1; Wed, 09 Aug 2023 12:31:20 -0400 X-MC-Unique: rhF_x51xNMSwv34nrQ4lig-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 62CA22804619; Wed, 9 Aug 2023 16:31:19 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4A9192026D4B; Wed, 9 Aug 2023 16:31:19 +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 EDC761946589; Wed, 9 Aug 2023 16:31:08 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 5EED31946588 for ; Wed, 9 Aug 2023 16:31:07 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id EA18840C6E8A; Wed, 9 Aug 2023 16:31:06 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast06.extmail.prod.ext.rdu2.redhat.com [10.11.55.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E2B1240C6F4E for ; Wed, 9 Aug 2023 16:31:06 +0000 (UTC) Received: from us-smtp-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 C40A6185A7A3 for ; Wed, 9 Aug 2023 16:31:06 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-138-f6Glo3weNT2sSo_XnBIjlg-1; Wed, 09 Aug 2023 12:31:03 -0400 X-MC-Unique: f6Glo3weNT2sSo_XnBIjlg-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 dfw.source.kernel.org (Postfix) with ESMTPS id 2611963262; Wed, 9 Aug 2023 16:31:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00FEDC433C8; Wed, 9 Aug 2023 16:30:53 +0000 (UTC) Message-ID: <2cb998ff14ace352a9dd553e82cfa0aa92ec09ce.camel@kernel.org> From: Jeff Layton To: OGAWA Hirofumi , Jan Kara Date: Wed, 09 Aug 2023 12:30:52 -0400 In-Reply-To: <87v8do6y8q.fsf@mail.parknet.co.jp> References: <20230807-mgctime-v7-0-d1dec143a704@kernel.org> <20230807-mgctime-v7-5-d1dec143a704@kernel.org> <87msz08vc7.fsf@mail.parknet.co.jp> <52bead1d6a33fec89944b96e2ec20d1ea8747a9a.camel@kernel.org> <878rak8hia.fsf@mail.parknet.co.jp> <20230809150041.452w7gucjmvjnvbg@quack3> <87v8do6y8q.fsf@mail.parknet.co.jp> 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.2 Subject: Re: [Cluster-devel] [PATCH v7 05/13] fat: make fat_update_time get its own timestamp 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 , "Darrick J. Wong" , Dominique Martinet , Christian Schoenebeck , ecryptfs@vger.kernel.org, Yue Hu , David Howells , Chris Mason , Andreas Dilger , Hans de Goede , Marc Dionne , linux-xfs@vger.kernel.org, linux-afs@lists.infradead.org, linux-mtd@lists.infradead.org, Mike Marshall , Paulo Alcantara , linux-cifs@vger.kernel.org, Eric Van Hensbergen , Miklos Szeredi , Richard Weinberger , Mark Fasheh , linux-unionfs@vger.kernel.org, Hugh Dickins , Tyler Hicks , cluster-devel@redhat.com, coda@cs.cmu.edu, linux-mm@kvack.org, Ilya Dryomov , Iurii Zaikin , Namjae Jeon , Trond Myklebust , codalist@telemann.coda.cs.cmu.edu, Shyam Prasad N , Amir Goldstein , Kees Cook , ocfs2-devel@lists.linux.dev, Chao Yu , Josef Bacik , Tom Talpey , Tejun Heo , Alexander Viro , Ronnie Sahlberg , David Sterba , Jaegeuk Kim , ceph-devel@vger.kernel.org, Xiubo Li , Gao Xiang , 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.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: kernel.org Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable On Thu, 2023-08-10 at 00:17 +0900, OGAWA Hirofumi wrote: > Jan Kara writes: >=20 > > Since you are talking past one another with Jeff let me chime in here := ). I > > think you are worried about this hunk: >=20 > Right. > > > -=09if ((flags & S_VERSION) && inode_maybe_inc_iversion(inode, false)) > > +=09if ((flags & (S_VERSION|S_CTIME|S_MTIME)) && inode_maybe_inc_iversi= on(inode, false)) > > =09=09dirty_flags |=3D I_DIRTY_SYNC; > >=20 > > which makes the 'flags' test pass even if we just modified ctime or mti= me. > > But do note the second part of the if - inode_maybe_inc_iversion() - so= we > > are going to mark the inode dirty with I_DIRTY_SYNC only if someone que= ried > > iversion since the last time we have incremented it. > >=20 > > So this hunk is not really changing how inode is marked dirty, it only > > changes how often we check whether iversion needs increment and that sh= ould > > be fine (and desirable). Hence lazytime isn't really broken by this in = any > > way. >=20 > OK. However, then it doesn't explain what I asked. This is not same with > generic_update_time(), only FAT does. > > If thinks it is right thing, why generic_update_time() doesn't? I said > first reply, this was from generic_update_time(). (Or I'm misreading > updated generic_update_time()?) >=20 My mistake re: lazytime vs. relatime, but Jan is correct that this shouldn't break anything there. The logic in the revised generic_update_time is different because FAT is is a bit strange. fat_update_time does extra truncation on the timestamp that it is handed beyond what timestamp_truncate() does. fat_truncate_time is called in many different places too, so I don't feel comfortable making big changes to how that works. In the case of generic_update_time, it calls inode_update_timestamps which returns a mask that shows which timestamps got updated. It then marks the dirty_flags appropriately for what was actually changed. generic_update_time is used across many filesystems so we need to ensure that it's OK to use even when multigrain timestamps are enabled. Those haven't been enabled in FAT though, so I didn't bother, and left it to dirtying the inode in the same way it was before, even though it now fetches its own timestamps from the clock. Given the way that the mtime and ctime are smooshed together in FAT, that seemed reasonable. Is there a particular case or flag combination you're concerned about here? --=20 Jeff Layton