From: i.r.e.c.c.a.k.u.n+kernel.org@gmail.com
To: linux-btrfs@vger.kernel.org
Subject: 'btrfs filesystem defragment' makes files explode in size, especially fallocated ones
Date: Sun, 4 Aug 2024 14:20:06 +0500 [thread overview]
Message-ID: <d190ad2e-26d5-4113-ab43-f39010b3896e@gmail.com> (raw)
(Originally reported on Kernel.org Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=219033)
There is a very weird quirk I found with 'btrfs filesystem defragment' command. And no, it's not about reflinks removal, I'm aware of that.
It is kinda hard to replicate, but I found a somewhat reliable way. It reaches extremes with fallocated files specifically.
1. Create a file on a Btrfs filesystem using 'fallocate' and fill it. The easy way to do that is just to copy some files with 'rsync --preallocate'.
2. Check compsize info:
# compsize foo
Processed 71 files, 71 regular extents (71 refs), 0 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 100% 630M 630M 630M
none 100% 630M 630M 630M
All is fine here for now. 1 extent per 1 file, "Disk Usage" = "Referenced".
3. Run defragment:
# btrfs filesystem defragment -r foo
4. Check compsize again:
# compsize foo
Processed 71 files, 76 regular extents (76 refs), 0 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 100% 638M 638M 630M
none 100% 638M 638M 630M
Oops, besides the fact that the amount of extents is actually increased, which means 'btrfs filesystem defragment' actually made fragmentation worse, physical disk usage increased for no reason. And I didn't find any way to shrink it back.
---
The end result seems to be random though. But I managed to achieve some truly horrifying results.
# compsize foo
Processed 45 files, 45 regular extents (45 refs), 0 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 100% 360M 360M 360M
none 100% 360M 360M 360M
# btrfs filesystem defragment -r -t 1G foo
# compsize foo
Processed 45 files, 144 regular extents (144 refs), 0 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 100% 716M 716M 360M
none 100% 716M 716M 360M
Yikes! Triple the extents! Double increase in size!
next reply other threads:[~2024-08-04 9:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-04 9:20 i.r.e.c.c.a.k.u.n+kernel.org [this message]
2024-08-04 22:19 ` 'btrfs filesystem defragment' makes files explode in size, especially fallocated ones Qu Wenruo
2024-08-05 18:16 ` Hanabishi
2024-08-05 22:47 ` Qu Wenruo
2024-08-06 7:19 ` Hanabishi
2024-08-06 9:55 ` Qu Wenruo
2024-08-06 10:23 ` Hanabishi
2024-08-06 10:42 ` Qu Wenruo
2024-08-06 11:05 ` Hanabishi
2024-08-06 11:23 ` Qu Wenruo
2024-08-06 12:08 ` Hanabishi
2024-08-06 22:10 ` Qu Wenruo
2024-08-06 22:42 ` Hanabishi
2024-08-06 22:51 ` Qu Wenruo
2024-08-06 23:04 ` Hanabishi
2024-08-06 12:17 ` Hanabishi
2024-08-06 13:22 ` Hanabishi
2024-08-06 22:18 ` Qu Wenruo
2024-08-06 22:55 ` Hanabishi
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=d190ad2e-26d5-4113-ab43-f39010b3896e@gmail.com \
--to=i.r.e.c.c.a.k.u.n+kernel.org@gmail.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