From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 3/3] btrfs: defrag: remove the physical adjacent extents rejection in defrag_check_next_extent()
Date: Wed, 26 Jan 2022 08:58:50 +0800 [thread overview]
Message-ID: <20220126005850.14729-3-wqu@suse.com> (raw)
In-Reply-To: <20220126005850.14729-1-wqu@suse.com>
There is a rejection for physically adjacent extents in
defrag_check_next_extent() from the very beginning.
The check will reject physically adjacent extents which are also large
enough.
The extent size threshold check is now a generic check, and the
benefit of rejecting physically adjacent extents is unsure.
Sure physically adjacent extents means no extra seek time, thus
defragging them may not bring much help.
On the other hand, btrfs also benefits from reduced number of extents
(which can reduce the size of extent tree, thus reduce the mount time).
So such rejection is not a full win.
Remove such check, and policy on which extents should be defragged is
mostly on @extent_thresh and @newer_than parameters.
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
fs/btrfs/ioctl.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 2911df12fc48..0929d08bb378 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1069,9 +1069,6 @@ static bool defrag_check_next_extent(struct inode *inode, struct extent_map *em,
/* Extent is already large enough */
if (next->len >= extent_thresh)
goto out;
- /* Physically adjacent */
- if ((em->block_start + em->block_len == next->block_start))
- goto out;
ret = true;
out:
free_extent_map(next);
--
2.34.1
next prev parent reply other threads:[~2022-01-26 0:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-26 0:58 [PATCH v3 1/3] btrfs: defrag: don't try to merge regular extents with preallocated extents Qu Wenruo
2022-01-26 0:58 ` [PATCH 2/3] btrfs: defrag: use extent_thresh to replace the hardcoded size limit Qu Wenruo
2022-01-26 11:40 ` Filipe Manana
2022-01-26 12:26 ` Qu Wenruo
2022-01-26 12:36 ` Filipe Manana
2022-01-26 13:00 ` Qu Wenruo
2022-01-26 13:37 ` Filipe Manana
2022-01-26 23:57 ` Qu Wenruo
2022-01-27 10:58 ` Filipe Manana
2022-01-27 11:11 ` Forza
2022-01-26 0:58 ` Qu Wenruo [this message]
2022-01-26 11:44 ` [PATCH 3/3] btrfs: defrag: remove the physical adjacent extents rejection in defrag_check_next_extent() Filipe Manana
2022-01-26 11:26 ` [PATCH v3 1/3] btrfs: defrag: don't try to merge regular extents with preallocated extents Filipe Manana
2022-01-26 11:33 ` Qu Wenruo
2022-01-26 11:47 ` Filipe Manana
2022-01-28 6:31 ` Qu Wenruo
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=20220126005850.14729-3-wqu@suse.com \
--to=wqu@suse.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox