btrfs: always update the logged transaction when logging new names

When we are logging a new name for an inode, due to a link or rename
operation, if the inode has ancestor inodes that are new, created in the
current transaction, we need to log that these inodes exist. To ensure
that a subsequent explicit fsync on one of these ancestor inodes does
sync the log, we don't set the logged_trans field of these inodes.
This was done in commit 75b463d2b47aef ("btrfs: do not commit logs and
transactions during link and rename operations"), to avoid syncing a
log after a rename or link operation.

In order to allow for future changes to do some optimizations, change
this behaviour to always update the logged_trans of any logged inode
and don't update the last_log_commit of the inode if we are logging
that it exists. This accomplishes that same objective with simpler
logic, allowing for some optimizations in the next patches.

So just do that simplification.

This patch is part of a patch set comprised of the following patches:

  btrfs: check if a log tree exists at inode_logged()
  btrfs: remove no longer needed checks for NULL log context
  btrfs: do not log new dentries when logging that a new name exists
  btrfs: always update the logged transaction when logging new names
  btrfs: avoid expensive search when dropping inode items from log
  btrfs: add helper to truncate inode items when logging inode
  btrfs: avoid expensive search when truncating inode items from the log
  btrfs: avoid search for logged i_size when logging inode if possible
  btrfs: avoid attempt to drop extents when logging inode for the first time
  btrfs: do not commit delayed inode when logging a file in full sync mode

This is patch 4/10 and test results are listed in the change log of the
last patch in the set.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>

diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index ccce82538b77cae1c5427d68c732db7bef615043..fc22cd81ea910c19fa96e6fd7310f081327460e0 100644 (file)
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -5569,47 +5569,42 @@ log_extents:
                }
        }
 
+       spin_lock(&inode->lock);
+       inode->logged_trans = trans->transid;
        /*
-        * If we are logging that an ancestor inode exists as part of logging a
-        * new name from a link or rename operation, don't mark the inode as
-        * logged - otherwise if an explicit fsync is made against an ancestor,
-        * the fsync considers the inode in the log and doesn't sync the log,
-        * resulting in the ancestor missing after a power failure unless the
-        * log was synced as part of an fsync against any other unrelated inode.
-        * So keep it simple for this case and just don't flag the ancestors as
-        * logged.
+        * Don't update last_log_commit if we logged that an inode exists.
+        * We do this for three reasons:
+        *
+        * 1) We might have had buffered writes to this inode that were
+        *    flushed and had their ordered extents completed in this
+        *    transaction, but we did not previously log the inode with
+        *    LOG_INODE_ALL. Later the inode was evicted and after that
+        *    it was loaded again and this LOG_INODE_EXISTS log operation
+        *    happened. We must make sure that if an explicit fsync against
+        *    the inode is performed later, it logs the new extents, an
+        *    updated inode item, etc, and syncs the log. The same logic
+        *    applies to direct IO writes instead of buffered writes.
+        *
+        * 2) When we log the inode with LOG_INODE_EXISTS, its inode item
+        *    is logged with an i_size of 0 or whatever value was logged
+        *    before. If later the i_size of the inode is increased by a
+        *    truncate operation, the log is synced through an fsync of
+        *    some other inode and then finally an explicit fsync against
+        *    this inode is made, we must make sure this fsync logs the
+        *    inode with the new i_size, the hole between old i_size and
+        *    the new i_size, and syncs the log.
+        *
+        * 3) If we are logging that an ancestor inode exists as part of
+        *    logging a new name from a link or rename operation, don't update
+        *    its last_log_commit - otherwise if an explicit fsync is made
+        *    against an ancestor, the fsync considers the inode in the log
+        *    and doesn't sync the log, resulting in the ancestor missing after
+        *    a power failure unless the log was synced as part of an fsync
+        *    against any other unrelated inode.
         */
-       if (!(S_ISDIR(inode->vfs_inode.i_mode) && ctx->logging_new_name &&
-             &inode->vfs_inode != ctx->inode)) {
-               spin_lock(&inode->lock);
-               inode->logged_trans = trans->transid;
-               /*
-                * Don't update last_log_commit if we logged that an inode exists.
-                * We do this for two reasons:
-                *
-                * 1) We might have had buffered writes to this inode that were
-                *    flushed and had their ordered extents completed in this
-                *    transaction, but we did not previously log the inode with
-                *    LOG_INODE_ALL. Later the inode was evicted and after that
-                *    it was loaded again and this LOG_INODE_EXISTS log operation
-                *    happened. We must make sure that if an explicit fsync against
-                *    the inode is performed later, it logs the new extents, an
-                *    updated inode item, etc, and syncs the log. The same logic
-                *    applies to direct IO writes instead of buffered writes.
-                *
-                * 2) When we log the inode with LOG_INODE_EXISTS, its inode item
-                *    is logged with an i_size of 0 or whatever value was logged
-                *    before. If later the i_size of the inode is increased by a
-                *    truncate operation, the log is synced through an fsync of
-                *    some other inode and then finally an explicit fsync against
-                *    this inode is made, we must make sure this fsync logs the
-                *    inode with the new i_size, the hole between old i_size and
-                *    the new i_size, and syncs the log.
-                */
-               if (inode_only != LOG_INODE_EXISTS)
-                       inode->last_log_commit = inode->last_sub_trans;
-               spin_unlock(&inode->lock);
-       }
+       if (inode_only != LOG_INODE_EXISTS)
+               inode->last_log_commit = inode->last_sub_trans;
+       spin_unlock(&inode->lock);
 out_unlock:
        mutex_unlock(&inode->log_mutex);