From: Roman Mamedov <rm@romanrm.net>
To: "Christian Völker" <cvoelker@knebb.de>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Removal of Device and Free Space
Date: Fri, 14 May 2021 22:06:12 +0500 [thread overview]
Message-ID: <20210514220612.6293aa23@natsu> (raw)
In-Reply-To: <850c35a8-0322-c60e-b179-b07eb0e1de8c@knebb.de>
On Fri, 14 May 2021 10:54:16 +0200
Christian Völker <cvoelker@knebb.de> wrote:
> What is occupying so much disk space as the data only has 1.7TB
> which should fit in 1.8TB (two) devices? (no snapshot, nothing special
> configured on btrfs). Looks like there are ~400GB allocated which are
> not from data.
Check if there are really no stray snapshots left over, which keep around old
versions of some of your data.
If not, it could be the infamous Btrfs "extent booking" inefficiency, where the
whole extent (up to 128 MB) is kept around as long as some part of it is still
referenced.
Discussed a bit here: https://www.spinics.net/lists/linux-btrfs/msg90352.html
Since then I found that not only VMs, but for example it's really
inefficient space-wise to download torrents onto a Btrfs (without nocow).
Anything where you overwrite small pieces within a large file, will waste
space.
In your case, if it's a backup server and you use rsync or the like in an
incremental mode updating only the changed blocks, switching that to
whole-file updates (-W for rsync) could alleviate the issue. Another way is to
force compression on the filesystem, which clamps the extent size limit down
from 128 MB to 128 KB and mitigates the problem in another way.
--
With respect,
Roman
next prev parent reply other threads:[~2021-05-14 17:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-14 8:54 Removal of Device and Free Space Christian Völker
2021-05-14 16:44 ` Andrei Borzenkov
2021-05-14 17:06 ` Roman Mamedov [this message]
2021-05-14 19:54 ` Christian Völker
2021-05-14 21:55 ` Remi Gauvin
2021-05-15 1:39 ` Zygo Blaxell
2021-05-15 7:48 ` Roman Mamedov
2021-05-16 18:41 ` Christian Völker
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=20210514220612.6293aa23@natsu \
--to=rm@romanrm.net \
--cc=cvoelker@knebb.de \
--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.