I've frequently seen free space cache corruption lead to phantom
ENOSPC. You could try clearing the space cache, and/or mounting with
nospache_cache.

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

Am 01.12.2016 um 09:12 schrieb Andrei Borzenkov:

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.

Is there otherwise a possibility to make the free space unallocated again?

Stefan

quoted

quoted

quoted

Try remounting with enoscp_debug, and then trigger the problem again,
and post the resulting kernel messages.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html