> > So, yes these are few corner cases which I want to take a deeper look at. > > I vaugely understand that this reset inode is done since we anyway might have > > done the full commit for previous tid, so we can reset the inode track range. > > > > So, yes, we should carefully review this as well that if jbd2 commit happens for > > an inode which is still part of MAIN_Q, then does it make sense to still > > call ext4_fc_reset_inode() for that inode in ext4_fc_track_template()? What this code assumes here is that if tid != ei->i_sync_tid, then the fast commit information present in the inode cannot be trusted. This is useful when the inode is added to the fast commit queue for the first ever or first time during the current transaction. Also note the "update" parameter, if update is set to false, then the track functions know that this is the first time the track function is called since the last (fast / full) commit. I think the simple invariant that we need to follow is that, once an inode is committed (either by fast or full commit) ext4_fc_reset_inode() should be called exactly once before any track functions get called. So, if we can ensure that reset gets called on all inodes that were committed by fast commit / full commit exactly once before any track functions update the fc info, then we don't really need this reset call here. > > > > 2. Also is this an expected behavior from the design perspective of > > > > fast_commit. i.e. > > > > a. the inode can be part of two tids?
