On 12/01/2016 09:12 AM, Andrei Borzenkov wrote:
> On Thu, Dec 1, 2016 at 10:49 AM, Stefan Priebe - Profihost AG
> <s.pri...@profihost.ag> wrote:
> ...
>>
>> Custom 4.4 kernel with patches up to 4.10. But i already tried 4.9-rc7
>> which does the same.
>>
>>
>>>> # 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?
>>
>>
>>> 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

>>> 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

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

Reply via email to