On Mon, Jun 27, 2016 at 9:24 PM, Chris Murphy [off-list ref] wrote:

On Mon, Jun 27, 2016 at 12:32 PM, Francesco Turco [off-list ref] wrote:

quoted

On 2016-06-27 20:18, Chris Murphy wrote:

quoted

If you can grab btrfs-debugfs from
https://github.com/kdave/btrfs-progs/blob/master/btrfs-debugfs

And then attach the output to the bug report it might be useful for a
developer. But really your case is an odd duck, because there's fully
14GiB unallocated, so it should be able to create a new one without
problem.

$ sudo ./btrfs-debugfs -b /

Done! Thank you, I was not aware of the existence of btrfs-debug...

I'm not certain what the "1 enospc errors during balance' refers to.
That message happens several times, the balance operation isn't
aborted, and doesn't come with any call traces (those appear later).
Further, the btrfs-debugfs output suggests the balance worked - each
bg is continguously located after the last and they're all new bg
offset values compared to what's found in the dmesg.

btrfs-debug does not show metadata ans system chunks; the balancing
problem might come from those.
This script does show all chunks:
https://github.com/knorrie/btrfs-heatmap/blob/master/show_usage.py

You might want to use vrange or drange balance filters so that you can
just target a certain chunk and maybe that gives a hint where the
problem might be. But anyhow, the behavior experienced is a bug.

This might be that obscure -28 enospc bug that affects some file
systems and hasn't been tracked down yet. If I recall correctly it's a
misleading error, and the only work around to get rid of it is migrate
to a new Btrfs file system. I don't think the file system is at any
risk in the current state, but I'm not certain as it's already an edge
case. I'd just make sure you keep suitably current backups and keep
using it.



--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html