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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4A056C05051 for ; Wed, 9 Aug 2023 16:31:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230176AbjHIQbC (ORCPT ); Wed, 9 Aug 2023 12:31:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52472 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229506AbjHIQbC (ORCPT ); Wed, 9 Aug 2023 12:31:02 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9A6C210F3; Wed, 9 Aug 2023 09:31:01 -0700 (PDT) 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 2950F63697; 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691598660; bh=Z7n9zJLdl712XVn1Py2iFtPG8LzL7lbCWNuqyD+/A3g=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=UPQGy8NQtXAAQ4aU3XYZHYnotv5CJersRvEj3UxLTDTNa1yXwNRn0IJiEHo/bl0VP UZsTGWxiaK4MtB7dfslKXsWsCHmiZVr63spdJLnJq8JDgcyekVH5Xc7NL7sGLhreu6 x15cmd+UhtlNWpehU4jYdveXB5k/7G4WPmTr0CQ6bDhyChBFc9/xsm+0Rn2qIx7rJs G7MVuLgnF5bvQR49Ipq6cF6+TvuMnXYBCNHAg7UV972mLj2aJnJNB5RVRDI4hEyHex /4cPUAWVkqpnS01ZlGmCOld61C8SWimdxp5ttui+xDqTyf2eAGc7ZrzDWG2FklGBAx JNZznme+soZDw== Message-ID: <2cb998ff14ace352a9dd553e82cfa0aa92ec09ce.camel@kernel.org> Subject: Re: [PATCH v7 05/13] fat: make fat_update_time get its own timestamp From: Jeff Layton To: OGAWA Hirofumi , Jan Kara Cc: Alexander Viro , Christian Brauner , 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 , Miklos Szeredi , Bob 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@telemann.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 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> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org 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. > > > - if ((flags & S_VERSION) && inode_maybe_inc_iversion(inode, false)) > > + if ((flags & (S_VERSION|S_CTIME|S_MTIME)) && inode_maybe_inc_iversion= (inode, false)) > > dirty_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 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 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 6D9D5C001B0 for ; Wed, 9 Aug 2023 16:31:09 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=UPQGy8NQ; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4RLbCb5NrDz3bWW for ; Thu, 10 Aug 2023 02:31:07 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=UPQGy8NQ; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=139.178.84.217; helo=dfw.source.kernel.org; envelope-from=jlayton@kernel.org; receiver=lists.ozlabs.org) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (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 lists.ozlabs.org (Postfix) with ESMTPS id 4RLbCW1LXcz2yhL for ; Thu, 10 Aug 2023 02:31:03 +1000 (AEST) 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691598660; bh=Z7n9zJLdl712XVn1Py2iFtPG8LzL7lbCWNuqyD+/A3g=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=UPQGy8NQtXAAQ4aU3XYZHYnotv5CJersRvEj3UxLTDTNa1yXwNRn0IJiEHo/bl0VP UZsTGWxiaK4MtB7dfslKXsWsCHmiZVr63spdJLnJq8JDgcyekVH5Xc7NL7sGLhreu6 x15cmd+UhtlNWpehU4jYdveXB5k/7G4WPmTr0CQ6bDhyChBFc9/xsm+0Rn2qIx7rJs G7MVuLgnF5bvQR49Ipq6cF6+TvuMnXYBCNHAg7UV972mLj2aJnJNB5RVRDI4hEyHex /4cPUAWVkqpnS01ZlGmCOld61C8SWimdxp5ttui+xDqTyf2eAGc7ZrzDWG2FklGBAx JNZznme+soZDw== Message-ID: <2cb998ff14ace352a9dd553e82cfa0aa92ec09ce.camel@kernel.org> Subject: Re: [PATCH v7 05/13] fat: make fat_update_time get its own timestamp 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> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 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 , "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 , Andreas Gruenbacher , Miklos Szeredi , Richard Weinberger , Mark Fasheh , linux-unionfs@vger.kernel.org, Hugh Dickins , Benjamin Coddington , 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, Josef Bacik , Tom Talpey , Tejun Heo , Alexander Viro , Ronnie Sahlberg , David Sterba , Jaegeuk Kim , ceph-devel@vger.kernel.org, Xiubo Li , 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 , devel@lists.orangefs.org, Anna Schumaker , Jan Kara , Bob Peterson , 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: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" 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. > > > - if ((flags & S_VERSION) && inode_maybe_inc_iversion(inode, false)) > > + if ((flags & (S_VERSION|S_CTIME|S_MTIME)) && inode_maybe_inc_iversion= (inode, false)) > > dirty_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 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.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (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 A5D3AC001E0 for ; Wed, 9 Aug 2023 16:31:14 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1qTm5X-00053v-LT; Wed, 09 Aug 2023 16:31:12 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qTm5X-00053p-7g for linux-f2fs-devel@lists.sourceforge.net; Wed, 09 Aug 2023 16:31:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=MIME-Version:Content-Transfer-Encoding:Content-Type :References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=y5zTR+vxWGRlvMSQR3R9jU//2eDeiTSiMZYjt/BtdFU=; b=FOVv8eZnSK3+BbnnyxrcVkvxAr ZjXms6o13vDtO8sBgQqZtHLVIewtI8V068DilosioXIvs1iLZTKL4OwuHUNUYvGzkxxOyp4VE//3F t29hk/yQDL2DKI2EU3sgIR9mMPyrp8k47MLDV10JoQiYTGZdAkJMFlCNb6ssF+G7vt/g=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=MIME-Version:Content-Transfer-Encoding:Content-Type:References: In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=y5zTR+vxWGRlvMSQR3R9jU//2eDeiTSiMZYjt/BtdFU=; b=m2JprllQBKqrjLMfMVxKTA8Xll GBB+0wRHrzl45tBaLIO/H2Q/srp+yNx9q+eQi+8U5s5vJfLFsswo4zwhJsyIHMNzubuxAuB52+08N tpHtpeRe9xGDGRhr4Tg3GLbiwk45UxYyb7fOR6YL/wP4cSMATPW0jjUKHLNazk20J9rw=; Received: from dfw.source.kernel.org ([139.178.84.217]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1qTm5S-000fce-SB for linux-f2fs-devel@lists.sourceforge.net; Wed, 09 Aug 2023 16:31:12 +0000 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691598660; bh=Z7n9zJLdl712XVn1Py2iFtPG8LzL7lbCWNuqyD+/A3g=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=UPQGy8NQtXAAQ4aU3XYZHYnotv5CJersRvEj3UxLTDTNa1yXwNRn0IJiEHo/bl0VP UZsTGWxiaK4MtB7dfslKXsWsCHmiZVr63spdJLnJq8JDgcyekVH5Xc7NL7sGLhreu6 x15cmd+UhtlNWpehU4jYdveXB5k/7G4WPmTr0CQ6bDhyChBFc9/xsm+0Rn2qIx7rJs G7MVuLgnF5bvQR49Ipq6cF6+TvuMnXYBCNHAg7UV972mLj2aJnJNB5RVRDI4hEyHex /4cPUAWVkqpnS01ZlGmCOld61C8SWimdxp5ttui+xDqTyf2eAGc7ZrzDWG2FklGBAx JNZznme+soZDw== 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-Headers-End: 1qTm5S-000fce-SB Subject: Re: [f2fs-dev] [PATCH v7 05/13] fat: make fat_update_time get its own timestamp X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: 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 , Andreas Gruenbacher , Miklos Szeredi , Richard Weinberger , Mark Fasheh , linux-unionfs@vger.kernel.org, Hugh Dickins , Benjamin Coddington , 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, 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 , Bob Peterson , 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Thu, 2023-08-10 at 00:17 +0900, OGAWA Hirofumi wrote: > Jan Kara writes: > > > Since you are talking past one another with Jeff let me chime in here :). I > > think you are worried about this hunk: > > Right. > > > - if ((flags & S_VERSION) && inode_maybe_inc_iversion(inode, false)) > > + if ((flags & (S_VERSION|S_CTIME|S_MTIME)) && inode_maybe_inc_iversion(inode, false)) > > dirty_flags |= I_DIRTY_SYNC; > > > > which makes the 'flags' test pass even if we just modified ctime or mtime. > > 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 queried > > iversion since the last time we have incremented it. > > > > 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 should > > be fine (and desirable). Hence lazytime isn't really broken by this in any > > way. > > 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()?) > 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? -- Jeff Layton _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel 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 AFC56C001B0 for ; Wed, 9 Aug 2023 16:31:16 +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: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=t2/WTobZrtDtedUM8kxtSa81hjoXP9CSlM8Uc3xVsHw=; b=WFYCoJh0Vgh9FG 9gqfCFFU0OvkuFwvPL9z9DwWn3TvhWGjHjDaWR9oDTA8EGs594WeXL+yDWDNBUKyFchMDe6Q56Fcf 6OpXnfoHn4RJyr8KCXbROyQqo815g/fHHIzP3X8R7f9JbcHgKKn6bNC1uMZL8TfMmuuLKV2PWl4AA A8FdBAZwBVWX4X1Xz9yPf6OjsAttUf0p/zisKxueBMApomvf1oTQmjp57BXu44ea/aNDi/a7NWEl5 BqzabAa4Lr9GIWVKrPUvHyVp3+qhSWkJRmwufM3h909XC6UFa0bYZnEQYQJL1WeNPpGjXCU9KnjOy +fBtTbq33kW78Bn/IzrA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qTm5R-005OrY-0v; Wed, 09 Aug 2023 16:31:05 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qTm5N-005Opr-25; Wed, 09 Aug 2023 16:31:03 +0000 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691598660; bh=Z7n9zJLdl712XVn1Py2iFtPG8LzL7lbCWNuqyD+/A3g=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=UPQGy8NQtXAAQ4aU3XYZHYnotv5CJersRvEj3UxLTDTNa1yXwNRn0IJiEHo/bl0VP UZsTGWxiaK4MtB7dfslKXsWsCHmiZVr63spdJLnJq8JDgcyekVH5Xc7NL7sGLhreu6 x15cmd+UhtlNWpehU4jYdveXB5k/7G4WPmTr0CQ6bDhyChBFc9/xsm+0Rn2qIx7rJs G7MVuLgnF5bvQR49Ipq6cF6+TvuMnXYBCNHAg7UV972mLj2aJnJNB5RVRDI4hEyHex /4cPUAWVkqpnS01ZlGmCOld61C8SWimdxp5ttui+xDqTyf2eAGc7ZrzDWG2FklGBAx JNZznme+soZDw== Message-ID: <2cb998ff14ace352a9dd553e82cfa0aa92ec09ce.camel@kernel.org> Subject: Re: [PATCH v7 05/13] fat: make fat_update_time get its own timestamp From: Jeff Layton To: OGAWA Hirofumi , Jan Kara Cc: Alexander Viro , Christian Brauner , 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 , Miklos Szeredi , Bob 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@telemann.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 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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230809_093101_766797_F6C3F22C X-CRM114-Status: GOOD ( 24.72 ) 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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Thu, 2023-08-10 at 00:17 +0900, OGAWA Hirofumi wrote: > Jan Kara writes: > > > Since you are talking past one another with Jeff let me chime in here :). I > > think you are worried about this hunk: > > Right. > > > - if ((flags & S_VERSION) && inode_maybe_inc_iversion(inode, false)) > > + if ((flags & (S_VERSION|S_CTIME|S_MTIME)) && inode_maybe_inc_iversion(inode, false)) > > dirty_flags |= I_DIRTY_SYNC; > > > > which makes the 'flags' test pass even if we just modified ctime or mtime. > > 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 queried > > iversion since the last time we have incremented it. > > > > 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 should > > be fine (and desirable). Hence lazytime isn't really broken by this in any > > way. > > 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()?) > 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? -- Jeff Layton ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/