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;
Date:   Mon, 21 Feb 2022 13:29:38 +0530
From:   Ritesh Harjani <riteshh@linux.ibm.com>
To:     Harshad Shirwadkar <harshadshirwadkar@gmail.com>,
        "Theodore Ts'o" <tytso@mit.edu>
Cc:     linux-ext4 <linux-ext4@vger.kernel.org>, Jan Kara <jack@suse.cz>
Subject: Query regarding fast_commit replay of inode
Message-ID: <20220221075938.g2lncbi7sxnnbrhr@riteshh-domain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: bulk

Hello Ted/Harshad,

I think we did discuss this once before, but I am unable to recollect the exact
reasoning for this. So question is - why do we have to call ext4_ext_clear_bb()
from ext4_fc_replay_inode()?

I was just thinking if this is suboptimal and if it can be optimized. But before
working on that problem, I wanted to again understand the right reasoning behind
choosing this approach in the first place.

Could you please help with this again?

ext4_fc_replay_inode()
<..>
	inode = ext4_iget(sb, ino, EXT4_IGET_NORMAL);
	if (!IS_ERR(inode)) {
		ext4_ext_clear_bb(inode);
		iput(inode);
	}
<..>

I will document it this time, so that I don't have to keep coming to this
everytime I look into fc replay code.

Thanks again for your help!!
-ritesh