From: Hans van Kranenburg <hans@knorrie.org>
To: Marc MERLIN <marc@merlins.org>, Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Roman Mamedov <rm@romanrm.net>,
Andrei Borzenkov <arvidjaar@gmail.com>,
linux-btrfs@vger.kernel.org
Subject: Re: How to find/reclaim missing space in volume
Date: Wed, 7 Jun 2023 21:32:13 +0200 [thread overview]
Message-ID: <a2a492ee-baa5-6881-e9ec-85ca2e611879@knorrie.org> (raw)
In-Reply-To: <20230607191719.GA12693@merlins.org>
Hi,
On 6/7/23 21:17, Marc MERLIN wrote:
> On Wed, Jun 07, 2023 at 10:12:30AM +0800, Qu Wenruo wrote:
>> For the ghost subvolumes, it can be confirmed with "btrfs ins dump-tree
>> -t root", then looking for ROOT_ITEMs with "refs 0".
>>
>> I'm not sure if it is the case.
>>
>> Another possible cause is extent bookends, this needs something like
>> btrfs quota to confirm, and not much we can do if there are snapshots.
>> (If no snapshots, it's possible to defrag and free up such bookend extents).
>
> unfortunately the system rebooted overnight, so I lost the state where
> sync was hung.
> On the plus side, this seems to have fixed the issue:
Just a random hint... One possible situation in which a deleted
subvolume can't be freed up for real yet, is when there is a process
that still has an open file in it.
> sauron:/mnt/btrfs_pool2# btrfs fi usage -T .
> Overall:
> Device size: 1.04TiB
> Device allocated: 857.02GiB
> Device unallocated: 210.73GiB
> Device missing: 0.00B
> Used: 589.30GiB
> Free (estimated): 470.78GiB (min: 365.42GiB)
> Data ratio: 1.00
> Metadata ratio: 2.00
> Global reserve: 512.00MiB (used: 0.00B)
>
> Data Metadata System
> Id Path single DUP DUP Unallocated
> -- ----------------- --------- -------- --------- -----------
> 1 /dev/mapper/pool2 845.00GiB 12.00GiB 16.00MiB 210.73GiB
> -- ----------------- --------- -------- --------- -----------
> Total 845.00GiB 6.00GiB 8.00MiB 210.73GiB
> Used 584.95GiB 2.18GiB 112.00KiB
> sauron:/mnt/btrfs_pool2# df -h .
> Filesystem Size Used Avail Use% Mounted on
> /dev/mapper/pool2 1.1T 590G 471G 56% /mnt/btrfs_pool2
>
> I know it's hard to say after the fact, but have you seen issues where snapshot delete
> space cleanup would get stuck and
> btrfs subvolume sync `pwd`
> would hang forever (until reboot) ?
Hans
next prev parent reply other threads:[~2023-06-07 19:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-05 16:26 How to find/reclaim missing space in volume Marc MERLIN
2023-06-05 16:47 ` Roman Mamedov
2023-06-05 17:00 ` Andrei Borzenkov
2023-06-06 1:46 ` Marc MERLIN
2023-06-06 4:47 ` Andrei Borzenkov
2023-06-06 16:41 ` Marc MERLIN
2023-06-06 18:25 ` Roman Mamedov
2023-06-07 2:12 ` Qu Wenruo
2023-06-07 19:17 ` Marc MERLIN
2023-06-07 19:32 ` Hans van Kranenburg [this message]
2023-06-07 20:02 ` Marc MERLIN
2023-06-07 20:31 ` Hans van Kranenburg
2023-06-06 18:19 ` Graham Cobb
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=a2a492ee-baa5-6881-e9ec-85ca2e611879@knorrie.org \
--to=hans@knorrie.org \
--cc=arvidjaar@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=marc@merlins.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=rm@romanrm.net \
/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