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 пишет: >> 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
