All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Cc: "Christian Völker" <cvoelker@knebb.de>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Removal of Device and Free Space
Date: Sat, 15 May 2021 12:48:03 +0500	[thread overview]
Message-ID: <20210515124803.41f88f70@natsu> (raw)
In-Reply-To: <20210515013903.GE32440@hungrycats.org>

On Fri, 14 May 2021 21:39:04 -0400
Zygo Blaxell <ce3g8jdj@umail.furryterror.org> 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.
> 
> Chunks are deallocated only when completely empty.  If you recently
> deleted a large number of files, then you'll have chunks with low data
> density and high free space fragmentation.  Normally this does not matter,
> as the free spaces in chunks would be filled in by new data allocations,
> and those allocations would split writes into smaller extents that exactly
> fit the free spaces.  Relocation can't do this--it can only occupy free
> spaces that are equal or larger, and will make free space fragmentation
> even worse.

Oh yeah, if you were just talking about discrepancy between "allocated" vs
"used", then it is what Zygo said, and my other reply regrading extent booking
doesn't apply here. That other issue is relevant only if you observe a
difference between "du [all files]" and "df [filesystem]".

-- 
With respect,
Roman

  reply	other threads:[~2021-05-15  7:48 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
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 [this message]
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=20210515124803.41f88f70@natsu \
    --to=rm@romanrm.net \
    --cc=ce3g8jdj@umail.furryterror.org \
    --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.