01.12.2016 18:48, Chris Murphy пишет: > On Thu, Dec 1, 2016 at 7:10 AM, Stefan Priebe - Profihost AG > <s.pri...@profihost.ag> wrote: >> >> Am 01.12.2016 um 14:51 schrieb Hans van Kranenburg: >>> 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 >> >> 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. > >>>>> 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. > > > -- 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
