On Tue, Aug 9, 2016 at 3:06 AM, Thomas <c.mo...@web.de> wrote: > thomas@pc8-nb:~$ uname -a > Linux pc8-nb 4.6.1-towo.1-siduction-amd64 #1 SMP PREEMPT siduction 4.6-1 > (2016-06-04) x86_64 GNU/Linux
Try 4.5.7 or 4.7 and see if it fixes the problem, there's a related patch in both of those that's not yet in 4.6 series. The patch mainly permits using existing chunks for balance to consolidate extents, rather than requiring new chunks. So you might also have to do a filtered balance. I would probably start with -dusage=25 and see where that gets you. > Device size: 20.53GiB > Device allocated: 20.53GiB >From Btrfs perspective the volume is "fully allocated" and as such cannot create new data or metadata chunks. Whatever workload you're doing at the time of enospc may be filling up data or metadata unused space in existing chunks, triggering need for newly allocated chunk, which can't happen because there's no space left for new chunks. > Data,single: Size:19.76GiB, Used:17.81GiB > /dev/sda8 19.76GiB > > Metadata,single: Size:776.00MiB, Used:455.73MiB > /dev/sda8 776.00MiB I'll guess there's some metadata centric workload, maybe with small files that are being stored inline, that's filling up the metadata chunks, leading to enospc. If changing kernel versions doesn't work, then you'll need to add more space somehow. The file system is ~90% full anyway. -- 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
