From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: Christoph Anton Mitterer <calestyo@scientia.org>
Subject: [PATCH] btrfs: defrag: add under utilized extent to defrag target list
Date: Fri, 5 Jan 2024 18:03:40 +1030 [thread overview]
Message-ID: <2c2fac36b67c97c9955eb24a97c6f3c09d21c7ff.1704440000.git.wqu@suse.com> (raw)
[BUG]
The following script can lead to a very under utilized extent and we
have no way to use defrag to properly reclaim its wasted space:
# mkfs.btrfs -f $dev
# mount $dev $mnt
# xfs_io -f -c "pwrite 0 128M" $mnt/foobar
# sync
# btrfs filesystem defrag $mnt/foobar
# sync
After the above operations, the file "foobar" is still utilizing the
whole 128M:
item 4 key (257 INODE_ITEM 0) itemoff 15883 itemsize 160
generation 7 transid 8 size 4096 nbytes 4096
block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0
sequence 32770 flags 0x0(none)
item 5 key (257 INODE_REF 256) itemoff 15869 itemsize 14
index 2 namelen 4 name: file
item 6 key (257 EXTENT_DATA 0) itemoff 15816 itemsize 53
generation 7 type 1 (regular)
extent data disk byte 298844160 nr 134217728 <<<
extent data offset 0 nr 4096 ram 134217728
extent compression 0 (none)
Meaning the expected defrag way to reclaim the space is not working.
[CAUSE]
The file extent has no adjacent extent at all, thus all existing defrag
code consider it a perfectly good file extent, even if it's only
utilizing a very tiny amount of space.
[FIX]
Add a special handling for under utilized extents, currently the ratio
is 6.25% (1/16).
This would allow us to add such extent to our defrag target list,
resulting it to be properly defragged.
Reported-by: Christoph Anton Mitterer <calestyo@scientia.org>
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
fs/btrfs/defrag.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/fs/btrfs/defrag.c b/fs/btrfs/defrag.c
index c276b136ab63..cc319190b6fb 100644
--- a/fs/btrfs/defrag.c
+++ b/fs/btrfs/defrag.c
@@ -1070,6 +1070,17 @@ static int defrag_collect_targets(struct btrfs_inode *inode,
if (!next_mergeable) {
struct defrag_target_range *last;
+ /*
+ * Special entry point utilization ratio under 1/16 (only
+ * referring 1/16 of an on-disk extent).
+ * This can happen for a truncated large extent.
+ * If we don't add them, then for a truncated file
+ * (may be the last 4K of a 128M extent) it will never
+ * be defraged.
+ */
+ if (em->ram_bytes < em->orig_block_len / 16)
+ goto add;
+
/* Empty target list, no way to merge with last entry */
if (list_empty(target_list))
goto next;
--
2.43.0
next reply other threads:[~2024-01-05 7:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-05 7:33 Qu Wenruo [this message]
2024-01-05 16:45 ` [PATCH] btrfs: defrag: add under utilized extent to defrag target list Andrei Borzenkov
2024-01-05 20:11 ` Qu Wenruo
2024-01-09 14:55 ` Filipe Manana
2024-01-09 16:12 ` Filipe Manana
2024-01-09 21:04 ` Qu Wenruo
2024-01-09 21:57 ` Christoph Anton Mitterer
2024-01-09 22:17 ` Qu Wenruo
2024-01-10 17:09 ` David Sterba
2024-01-11 6:24 ` Qu Wenruo
2024-01-12 15:58 ` David Sterba
2024-01-13 3:17 ` Qu Wenruo
2024-01-13 8:05 ` Andrei Borzenkov
2024-01-13 8:32 ` Qu Wenruo
2024-01-13 3:47 ` Christoph Anton Mitterer
2024-02-05 5:39 ` Christoph Anton Mitterer
2024-02-05 5:42 ` Qu Wenruo
2024-04-20 4:30 ` Skirnir Torvaldsson
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=2c2fac36b67c97c9955eb24a97c6f3c09d21c7ff.1704440000.git.wqu@suse.com \
--to=wqu@suse.com \
--cc=calestyo@scientia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).