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!
prev parent 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).