All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.