On 03/14/16 13:07, Marc Haber wrote: >> And btrfs balance runs into the same ENOSPC issues as the old one: > > ... with Qu's patch, I now get a reproducible kernel trace:
<snip> That is interesting and useful. Sorry if this was asked before, but did you ever try to clear the free-space cache via -o clear_cache on mount? Give it a try, let it run for a while and then try balancing again. There is definitely something wrong with the chunk allocation on your system since you still have allegedly ~100G free, so it's not the notorious (and a lot less common these days) edge case of sparsely populated chunks that would require a 'compaction'. IMHO you are also looking at two different, possibly unrelated problems: failure to allocate more chunks vs. metadata bloat, so let's not confuse the two. Uncle Occam's razor also suggests that the involvement of dm doesn't help. Why not just use the device/partition directly? _Someone_ is lying to btrfs in terms of device size and/or allocated chunks, otherwise you wouldn't get the ENOSPC. -h -- 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
