On Sun, Mar 6, 2016 at 1:27 PM, Chris Murphy <li...@colorremedies.com> wrote:
> So if it were me, I'd gather all possible data, including complete, > not trimmed, logs. Also include in the bug, the balance script being used. It might be a contributing factor. I wonder if the ENOSPC is happening just prior to the point where balance would free up the unused portion of allocated metadata chunks and that's why this just keeps getting worse? The balance function is COW, so I wonder if there are a bunch of failed chunk migrations that are just accumulating due to the ENOSPC stopping the balance? Anyway, after collecting all data and btrfs-image, I would blow away this fs using current kernel and tools. And then go back to the original workload. I would not pare down the number or frequency of snapshots. If anything increase it. The idea is to reproduce the bug. While ENOSPC is a certain indicator the bug is present, it's not the only possibility. If the metadata chunk allocation substantially starts to exceed the used amount by say 4x or more after a full metadata balance, that suggests a problem even if there is no ENOSPC. Right now total is more than 50x 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
