Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp3548061rwb; Tue, 16 Aug 2022 05:11:11 -0700 (PDT) X-Google-Smtp-Source: AA6agR4Z7r7kCSJrgeDArh8ojg9IgWY6xR3g2M5oO6mCWIV5phhpFvFdvJWHC3Z3PItLBmaJaW7I X-Received: by 2002:a17:907:7348:b0:731:535e:abc7 with SMTP id dq8-20020a170907734800b00731535eabc7mr13702220ejc.274.1660651871469; Tue, 16 Aug 2022 05:11:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660651871; cv=none; d=google.com; s=arc-20160816; b=EhetDK+Szhf40x8jhFpqRa9kJDUD3G1iNG3gr/bjDZXwb6HZF07yJJGQhGIyUKnlmk vomnvUuq381GnbmLWyv/YeLSC8jDvIvqysvzxpN6sBpMDhKlKk5mrFIB6GLAfoapLBZo Y3lxomVDaJntmCak4l7CU/sjGPsHRpj+jWaYFFxFF+QOfHXz+fZzSk5/wE+dACahsIC+ luvxuJdUEjPU5G+Xwlhd2SPX85+4o2sk+2eqcT9uKCEZ22kUPPmDErogOdGkXaEFHFa3 cbhw+/FyoK0XI1kilSIdV/zwqGpHQ6IUhraQ7SNa/EfLa9fwpiKqfAadlIzIu1TM2JCu MQ2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=pm9H1mLMuxBifvpl8R+KWSy9XKybiqGOTBkfvvveSCQ=; b=MwvzE3ostDMz4sBnAWKAOz5A5dJfwcQ2vugXkUXBmRm7YtZm1KMCNbZTxZ9m3WMRl1 AoCN+ZTkfRywkU7O+YAqaYE95ne+V9ns3nKOiMoEhAlxLZFAMAy5G8Euhp20QBx83YmY 1kvSLbWzIagUywg/fkZxXMonkKa7xqv9plRXWPUclphJvdUSYX9BywYpiI3ue8Aaetfg JIgdOsq+9w2lggx/rd3ZZYfgIe8hLZRhi176+dF+o09/birPCX81S5kWTcQeiKkjHYyu b/c2/IyfKPAhVoBWwBweFNynhZ9A1p5ljrdsNCv/enSWgs8iNO3xQ7LMzQLg8IzLVaGQ xKUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=GvZIDXDb; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i13-20020a1709064fcd00b00734bbe8d2f7si10881183ejw.952.2022.08.16.05.10.46; Tue, 16 Aug 2022 05:11:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=GvZIDXDb; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235233AbiHPMFa (ORCPT + 99 others); Tue, 16 Aug 2022 08:05:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234817AbiHPMFG (ORCPT ); Tue, 16 Aug 2022 08:05:06 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E329B6016; Tue, 16 Aug 2022 04:52:50 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 358F51FB22; Tue, 16 Aug 2022 11:52:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1660650769; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pm9H1mLMuxBifvpl8R+KWSy9XKybiqGOTBkfvvveSCQ=; b=GvZIDXDbsBaXWRc20mHJ8mNjye+kyz6tweEU4L7nulXRKObKoMd/ZO3S6eUI1u8BCisi8i dN1Zck7aU2re7joXtJSXVHm7qUeBqAW5DOppre79bN1yv5JGMdP3pZwuV8Ezcw7CqRfmop JO1Yp8vM5TfcGVUquDXrHk3pXTnCgwQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1660650769; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pm9H1mLMuxBifvpl8R+KWSy9XKybiqGOTBkfvvveSCQ=; b=fE+IndYeWcT1MbkYhoCw1O4fFZIvHFQ1VEIZYEO/Jq32rbnRrb0fyAzhcPE2VMesnC8L/V dK+YX3sC9ULZAtDA== Received: from quack3.suse.cz (unknown [10.100.224.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 1D0862C149; Tue, 16 Aug 2022 11:52:49 +0000 (UTC) Received: by quack3.suse.cz (Postfix, from userid 1000) id 8D382A066C; Tue, 16 Aug 2022 13:52:48 +0200 (CEST) Date: Tue, 16 Aug 2022 13:52:48 +0200 From: Jan Kara To: Jeff Layton Cc: Lukas Czerner , linux-ext4@vger.kernel.org, tytso@mit.edu, jack@suse.cz, linux-fsdevel@vger.kernel.org, ebiggers@kernel.org, david@fromorbit.com Subject: Re: [PATCH v3 1/3] ext4: don't increase iversion counter for ea_inodes Message-ID: <20220816115248.2xj25pcays7dkrpp@quack3> References: <20220812123727.46397-1-lczerner@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_SOFTFAIL, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Fri 12-08-22 14:42:36, Jeff Layton wrote: > On Fri, 2022-08-12 at 14:37 +0200, Lukas Czerner wrote: > > ea_inodes are using i_version for storing part of the reference count so > > we really need to leave it alone. > > > > The problem can be reproduced by xfstest ext4/026 when iversion is > > enabled. Fix it by not calling inode_inc_iversion() for EXT4_EA_INODE_FL > > inodes in ext4_mark_iloc_dirty(). > > > > Signed-off-by: Lukas Czerner > > Reviewed-by: Jan Kara > > Reviewed-by: Jeff Layton > > --- > > v2, v3: no change > > > > fs/ext4/inode.c | 7 ++++++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c > > index 601214453c3a..2a220be34caa 100644 > > --- a/fs/ext4/inode.c > > +++ b/fs/ext4/inode.c > > @@ -5731,7 +5731,12 @@ int ext4_mark_iloc_dirty(handle_t *handle, > > } > > ext4_fc_track_inode(handle, inode); > > > > - if (IS_I_VERSION(inode)) > > + /* > > + * ea_inodes are using i_version for storing reference count, don't > > + * mess with it > > + */ > > + if (IS_I_VERSION(inode) && > > + !(EXT4_I(inode)->i_flags & EXT4_EA_INODE_FL)) > > inode_inc_iversion(inode); > > > > /* the do_update_inode consumes one bh->b_count */ > > > I've spent some time writing tests for the i_version counter (still > quite rough right now), and what I've found is that this particular > inode_inc_iversion results in the counter being bumped on _reads_ as > well as writes, due to the atime changing. This call to > inode_inc_iversion seems to make no sense, as we aren't bumping the > mtime here. > > I'm still working on and testing this, but I think we'll probably just > want to remove this inode_inc_iversion entirely, and leave the i_version > bumping for normal files to happen when the timestamps are updated. So > far, my testing seems to indicate that that does the right thing. I agree that inode_inc_iversion() may be overly agressive here but where else does get iversion updated for things like inode owner update or permission changes? Honza -- Jan Kara SUSE Labs, CR