linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Martin Mlynář" <nextsux@gmail.com>
To: Hans van Kranenburg <hans.van.kranenburg@mendix.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: Root volume (ID 5) in deleting state
Date: Tue, 14 Feb 2017 11:58:22 +0100	[thread overview]
Message-ID: <0f9815fc-c36d-7569-a6d1-ed0d63b9ee87@gmail.com> (raw)
In-Reply-To: <e6162766-c862-0098-858f-198e6f88e060@mendix.com>


>> It looks you're right!
>>
>> On a different machine:
>>
>> # btrfs sub list / | grep -v lxc
>> ID 327 gen 1959587 top level 5 path mnt/reaver
>> ID 498 gen 593655 top level 5 path var/lib/machines
>>
>> # btrfs sub list / -d | wc -l
>> 0
> Ok, apparently it's a regression in one of the latest versions then.
> But, it seems quite harmless.
I'm glad my data are safe :)

>
>>
>>>> # uname -a
>>>> Linux interceptor 4.9.6-1-ARCH #1 SMP PREEMPT Thu Jan 26 09:22:26 CET
>>>> 2017 x86_64 GNU/Linux
>>>>
>>>> # btrfs fi show  /
>>>> Label: none  uuid: 859dec5c-850c-4660-ad99-bc87456aa309
>>>>       Total devices 1 FS bytes used 132.89GiB
>>>>       devid    1 size 200.00GiB used 200.00GiB path
>>>> /dev/mapper/vg0-btrfsroot
>>> As a side note, all of your disk space is allocated (200GiB of 200GiB).
>>>
>>> Even while there's still 70GiB of free space scattered around inside,
>>> this might lead to out-of-space issues, depending on how badly
>>> fragmented that free space is.
>> I have not noticed this at all!
>>
>> # btrfs fi show /
>> Label: none  uuid: 859dec5c-850c-4660-ad99-bc87456aa309
>>      Total devices 1 FS bytes used 134.23GiB
>>      devid    1 size 200.00GiB used 200.00GiB path /dev/mapper/vg0-btrfsroot
>>
>> # btrfs fi df /
>> Data, single: total=195.96GiB, used=131.58GiB
>> System, single: total=3.00MiB, used=48.00KiB
>> Metadata, single: total=4.03GiB, used=2.64GiB
>> GlobalReserve, single: total=512.00MiB, used=0.00B
>>
>> After btrfs defrag there is no difference. btrfs fi show says still
>> 200/200. I'll try to play with it.

[ ... ]
>> So, to get the numbers of total raw disk space allocation down, you need
>> to defragment free space (compact the data), not defrag used space.
>>
>> You can even create pictures of space utilization in your btrfs
>> filesystem, which might help understanding what it looks like right now: \o/
>>
>> https://github.com/knorrie/btrfs-heatmap/
I've run into your tool yesterday while googling around this - thanks, 
it's really nice tool. Now rebalance is running and it seems to work well.

Thank you for excellent responses and help!




      reply	other threads:[~2017-02-14 10:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-13 11:26 Root volume (ID 5) in deleting state Martin Mlynář
2017-02-13 20:03 ` Hans van Kranenburg
2017-02-13 20:50   ` Martin Mlynář
2017-02-13 23:04     ` Hans van Kranenburg
2017-02-14 10:58       ` Martin Mlynář [this message]

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=0f9815fc-c36d-7569-a6d1-ed0d63b9ee87@gmail.com \
    --to=nextsux@gmail.com \
    --cc=hans.van.kranenburg@mendix.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;
as well as URLs for NNTP newsgroup(s).