isn't there a way to move free space to unallocated space again?


Am 03.12.2016 um 05:43 schrieb Andrei Borzenkov:

01.12.2016 18:48, Chris Murphy пишет:

quoted

On Thu, Dec 1, 2016 at 7:10 AM, Stefan Priebe - Profihost AG
[off-list ref] wrote:

quoted

Am 01.12.2016 um 14:51 schrieb Hans van Kranenburg:

quoted

On 12/01/2016 09:12 AM, Andrei Borzenkov wrote:

quoted

On Thu, Dec 1, 2016 at 10:49 AM, Stefan Priebe - Profihost AG
[off-list ref] wrote:
...

quoted

Custom 4.4 kernel with patches up to 4.10. But i already tried 4.9-rc7
which does the same.

quoted

quoted

# btrfs filesystem show /ssddisk/
Label: none  uuid: a69d2e90-c2ca-4589-9876-234446868adc
        Total devices 1 FS bytes used 305.67GiB
        devid    1 size 500.00GiB used 500.00GiB path /dev/vdb1

# btrfs filesystem usage /ssddisk/
Overall:
    Device size:                 500.00GiB
    Device allocated:            500.00GiB
    Device unallocated:            1.05MiB

Drive is actually fully allocated so if Btrfs needs to create a new
chunk right now, it can't. However,

Yes but there's lot of free space:
    Free (estimated):            193.46GiB      (min: 193.46GiB)

How does this match?

quoted

All three chunk types have quite a bit of unused space in them, so
it's unclear why there's a no space left error.

I remember discussion that balance always tries to pre-allocate one
chunk in advance, and I believe there was patch to correct it but I am
not sure whether it was merged.

http://www.spinics.net/lists/linux-btrfs/msg56772.html

Thanks - still don't understand why that one is not upstream or why it
was reverted. Looks absolutely reasonable to me.

It is upstream and hasn't been reverted.

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/fs/btrfs/volumes.c?id=refs/tags/v4.8.11
line 3650

I would try Duncan's idea of using just one filter and seeing what happens:

'btrfs balance start -dusage=1 <mp>'

Actually I just hit exactly the same symptoms on my VM where device was
fully allocated and metadata balance failed, but data balance succeeded
to free up space which allowed metadata balance to run too. This is
under 4.8.10.

So it appears that balance logic between data and metadata is somehow
different.

As this VM gets in 100% allocated condition fairly often I'd try to get
better understanding next time.

quoted

quoted

quoted

quoted

quoted

With enospc debug it says:
[39193.425682] BTRFS warning (device vdb1): no space to allocate a new
chunk for block group 839941881856
[39193.426033] BTRFS info (device vdb1): 1 enospc errors during balance

It might be nice if this stated what kind of chunk it's trying to allocate.