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. Other option would be to make it possible to make allocated unused space unallocted again - no idea how todo that. > >>>> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
