Too early report, the issue is back. Back to testing....
2016-07-07 12:18 GMT+02:00 Stanislaw Kaminski <stasheck.f...@gmail.com>: > Hi all, > I downgraded to 4.4.1-1 - all fine, 4.5.5.-1 - also fine, then got > back to 4.6.3-2 - and it's still fine. Apparently running under > different kernel somehow fixed the glitch (as far as I can test...). > > That leaves me with the other question: before issues, I 1.6 TiB was > used, now all the tools report 1.7 TiB issued (except for btrfs fs du > /home, this reports 1.6 TiB). How is that possible? > > Cheers, > Stan > > 2016-07-06 19:42 GMT+02:00 Chris Murphy <li...@colorremedies.com>: >> On Wed, Jul 6, 2016 at 3:55 AM, Stanislaw Kaminski >> <stasheck.f...@gmail.com> wrote: >> >>> Device unallocated: 97.89GiB >> >> There should be no problem creating any type of block group from this >> much space. It's a bug. >> >> I would try regression testing. Kernel 4.5.7 has some changes that may >> or may not relate to this (they should only relate when there is no >> unallocated space left) so you could try 4.5.6 and 4.5.7. And also >> 4.4.14. >> >> But also the kernel messages are important. There is this obscure >> enospc with error -28, so either with or without enospc_debug mount >> option is useful to try in 4.6.3 (I think it's less useful in older >> kernels). >> >> But do try nospace_cache first. If that works, you could then mount >> with clear_cache one time and see if that provides an enduring fix. It >> can take some time to rebuild the cache after clear_cache is used. >> >> >> >> -- >> Chris Murphy -- 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
