Commit d17260fd authored by Jeff Layton's avatar Jeff Layton

xfs: avoid setting XFS_ILOG_CORE if i_version doesn't need incrementing

If XFS_ILOG_CORE is already set then go ahead and increment it.
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
Acked-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
Acked-by: default avatarDave Chinner <dchinner@redhat.com>
parent e38cf302
......@@ -112,15 +112,17 @@ xfs_trans_log_inode(
/*
* First time we log the inode in a transaction, bump the inode change
* counter if it is configured for this to occur. We don't use
* inode_inc_version() because there is no need for extra locking around
* i_version as we already hold the inode locked exclusively for
* metadata modification.
* counter if it is configured for this to occur. While we have the
* inode locked exclusively for metadata modification, we can usually
* avoid setting XFS_ILOG_CORE if no one has queried the value since
* the last time it was incremented. If we have XFS_ILOG_CORE already
* set however, then go ahead and bump the i_version counter
* unconditionally.
*/
if (!(ip->i_itemp->ili_item.li_desc->lid_flags & XFS_LID_DIRTY) &&
IS_I_VERSION(VFS_I(ip))) {
inode_inc_iversion(VFS_I(ip));
flags |= XFS_ILOG_CORE;
if (inode_maybe_inc_iversion(VFS_I(ip), flags & XFS_ILOG_CORE))
flags |= XFS_ILOG_CORE;
}
tp->t_flags |= XFS_TRANS_DIRTY;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment