From: fdmanana@kernel.org
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 03/10] btrfs: do not log new dentries when logging that a new name exists
Date: Tue, 31 Aug 2021 15:30:33 +0100 [thread overview]
Message-ID: <337655916e1c56779148d3b4fa275139a993e004.1630419897.git.fdmanana@suse.com> (raw)
In-Reply-To: <cover.1630419897.git.fdmanana@suse.com>
From: Filipe Manana <fdmanana@suse.com>
When logging a new name for an inode, due to a link or rename operation,
we don't need to log all new dentries of the parent directories and their
subdirectories. We only want to log the names of the inode and that any
new parent directories exist. So in this case don't trigger logging of
the new dentries, that is only need when doing an explicit fsync on a
directory or on a file which requires logging its parent directories.
This avoids unnecessary work and reduces contention on the extent buffers
of a log tree.
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 3/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>
---
fs/btrfs/tree-log.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 7f5c586efe3c..27b0c908b10c 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -5695,6 +5695,14 @@ static int log_new_dir_dentries(struct btrfs_trans_handle *trans,
struct btrfs_dir_list *dir_elem;
int ret = 0;
+ /*
+ * If we are logging a new name, as part of a link or rename operation,
+ * don't bother logging new dentries, as we just want to log the names
+ * of an inode and that any new parents exist.
+ */
+ if (ctx->logging_new_name)
+ return 0;
+
path = btrfs_alloc_path();
if (!path)
return -ENOMEM;
--
2.28.0
next prev parent reply other threads:[~2021-08-31 14:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-31 14:30 [PATCH 00/10] btrfs: set of small optimizations for inode logging fdmanana
2021-08-31 14:30 ` [PATCH 01/10] btrfs: check if a log tree exists at inode_logged() fdmanana
2021-08-31 14:30 ` [PATCH 02/10] btrfs: remove no longer needed checks for NULL log context fdmanana
2021-08-31 14:30 ` fdmanana [this message]
2021-08-31 14:30 ` [PATCH 04/10] btrfs: always update the logged transaction when logging new names fdmanana
2021-08-31 14:30 ` [PATCH 05/10] btrfs: avoid expensive search when dropping inode items from log fdmanana
2021-08-31 14:30 ` [PATCH 06/10] btrfs: add helper to truncate inode items when logging inode fdmanana
2021-08-31 14:30 ` [PATCH 07/10] btrfs: avoid expensive search when truncating inode items from the log fdmanana
2021-08-31 14:30 ` [PATCH 08/10] btrfs: avoid search for logged i_size when logging inode if possible fdmanana
2021-08-31 14:30 ` [PATCH 09/10] btrfs: avoid attempt to drop extents when logging inode for the first time fdmanana
2021-08-31 14:30 ` [PATCH 10/10] btrfs: do not commit delayed inode when logging a file in full sync mode fdmanana
2021-09-02 16:56 ` [PATCH 00/10] btrfs: set of small optimizations for inode logging David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=337655916e1c56779148d3b4fa275139a993e004.1630419897.git.fdmanana@suse.com \
--to=fdmanana@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.