linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Brendan Hide <brendan@swiftspirit.co.za>, linux-btrfs@vger.kernel.org
Subject: Re: Allocator behaviour during device delete
Date: Thu, 9 Jun 2016 09:07:14 -0400	[thread overview]
Message-ID: <f88b62ed-1e17-2f67-8d0d-210ad96cace5@gmail.com> (raw)
In-Reply-To: <00ad8257-ba24-fe62-5c93-8db426afec69@swiftspirit.co.za>

On 2016-06-09 08:34, Brendan Hide wrote:
> Hey, all
>
> I noticed this odd behaviour while migrating from a 1TB spindle to SSD
> (in this case on a LUKS-encrypted 200GB partition) - and am curious if
> this behaviour I've noted below is expected or known. I figure it is a
> bug. Depending on the situation, it *could* be severe. In my case it was
> simply annoying.
>
> ---
> Steps
>
> After having added the new device (btrfs dev add), I deleted the old
> device (btrfs dev del)
>
> Then, whilst waiting for that to complete, I started a watch of "btrfs
> fi show /". Note that the below is very close to the output at the time
> - but is not actually copy/pasted from the output.
>
>> Label: 'tricky-root'  uuid: bcbe47a5-bd3f-497a-816b-decb4f822c42
>>         Total devices 2 FS bytes used 115.03GiB
>>         devid    1 size 0.00GiB used 298.06GiB path /dev/sda2
>>         devid    2 size 200.88GiB used 0.00GiB path /dev/mapper/cryptroot
>
>
> devid1 is the old disk while devid2 is the new SSD
>
> After a few minutes, I saw that the numbers have changed - but that the
> SSD still had no data:
>
>> Label: 'tricky-root'  uuid: bcbe47a5-bd3f-497a-816b-decb4f822c42
>>         Total devices 2 FS bytes used 115.03GiB
>>         devid    1 size 0.00GiB used 284.06GiB path /dev/sda2
>>         devid    2 size 200.88GiB used 0.00GiB path /dev/mapper/cryptroot
>
> The "FS bytes used" amount was changing a lot - but mostly stayed near
> the original total, which is expected since there was very little
> happening other than the "migration".
>
> I'm not certain of the exact point where it started using the new disk's
> space. I figure that may have been helpful to pinpoint. :-/
OK, I'm pretty sure I know what was going on in this case.  Your 
assumption that device delete uses the balance code is correct, and that 
is why you see what's happening happening.  There are two key bits that 
are missing though:
1. Balance will never allocate chunks when it doesn't need to.
2. The space usage listed in fi show is how much space is allocated to 
chunks, not how much is used in those chunks.

In this case, based on what you've said, you had a lot of empty or 
mostly empty chunks.  As a result of this, the device delete was both 
copying data, and consolidating free space.  If you have a lot of empty 
or mostly empty chunks, it's not unusual for a device delete to look 
like this until you start hitting chunks that have actual data in them. 
The pri8mary point of this behavior is that it makes it possible to 
directly switch to a smaller device without having to run a balance and 
then a resize before replacing the device, and then resize again afterwards.

  reply	other threads:[~2016-06-09 13:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-09 12:34 Allocator behaviour during device delete Brendan Hide
2016-06-09 13:07 ` Austin S. Hemmelgarn [this message]
2016-06-09 13:54   ` Brendan Hide
2016-06-10 19:26     ` Henk Slager
2016-06-10 19:58       ` Hans van Kranenburg
2016-06-10 22:31         ` Hans van Kranenburg
2016-06-13 11:09       ` Austin S. Hemmelgarn

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=f88b62ed-1e17-2f67-8d0d-210ad96cace5@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=brendan@swiftspirit.co.za \
    --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 NNTP newsgroup(s).