xfs: log timestamp updates

Timestamps on regular files are the last metadata that XFS does not update
transactionally.  Now that we use the delaylog mode exclusively and made
the log scode scale extremly well there is no need to bypass that code for
timestamp updates.  Logging all updates allows to drop a lot of code, and
will allow for further performance improvements later on.

Note that this patch drops optimized handling of fdatasync - it will be
added back in a separate commit.

Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>

1 files changed, 0 insertions, 36 deletions

diff --git a/fs/xfs/xfs_inode_item.c b/fs/xfs/xfs_inode_item.c
index adc8a261b5d0..7a60da64f31d 100644
--- a/fs/xfs/xfs_inode_item.c
+++ b/fs/xfs/xfs_inode_item.c
@@ -254,42 +254,6 @@ xfs_inode_item_format(
         vecp++;
         nvecs        = 1;
 
-        /*
-         * Clear i_update_core if the timestamps (or any other
-         * non-transactional modification) need flushing/logging
-         * and we're about to log them with the rest of the core.
-         *
-         * This is the same logic as xfs_iflush() but this code can't
-         * run at the same time as xfs_iflush because we're in commit
-         * processing here and so we have the inode lock held in
-         * exclusive mode.  Although it doesn't really matter
-         * for the timestamps if both routines were to grab the
-         * timestamps or not.  That would be ok.
-         *
-         * We clear i_update_core before copying out the data.
-         * This is for coordination with our timestamp updates
-         * that don't hold the inode lock. They will always
-         * update the timestamps BEFORE setting i_update_core,
-         * so if we clear i_update_core after they set it we
-         * are guaranteed to see their updates to the timestamps
-         * either here.  Likewise, if they set it after we clear it
-         * here, we'll see it either on the next commit of this
-         * inode or the next time the inode gets flushed via
-         * xfs_iflush().  This depends on strongly ordered memory
-         * semantics, but we have that.  We use the SYNCHRONIZE
-         * macro to make sure that the compiler does not reorder
-         * the i_update_core access below the data copy below.
-         */
-        if (ip->i_update_core)  {
-                ip->i_update_core = 0;
-                SYNCHRONIZE();
-        }
-
-        /*
-         * Make sure to get the latest timestamps from the Linux inode.
-         */
-        xfs_synchronize_times(ip);
-
         vecp->i_addr = &ip->i_d;
         vecp->i_len  = sizeof(struct xfs_icdinode);
         vecp->i_type = XLOG_REG_TYPE_ICORE;