(In reply to Wenruo Qu from comment #10) > Btrfs qgroup limit calculation, is based on the principle of, never exceed > the limit even it could return early EDQUOT. > > The main challenge for btrfs qgroup is, its reserved metadata space > calculation is pretty unreliable. We over-reserve metadata space even for > non-qgroup use cases. > > So current btrfs uses an optimistic method, if we're low on available space, > we try to commit transaction in another thread (commit_kthread) to free some > space. > This behavior is not ensured to free enough space before we hit the limit, > so we could have unexpected EDQUOT related to various factors like system > load. > > The current behavior almost works fine for x86_64, but since we don't have > ppc64 system to test, I guess it's more obvious to fail such optimistic > tries. > > Would it be possible to mark that test as soft fail? As we don't have a good > idea to completely fix it soon. The interesting thing is that the failing line is https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/console/btrfs_qgroups.pm#L105 which is already within a "soft-fail workaround" section referencing bug 1113042 introduced in https://github.com/os-autoinst/os-autoinst-distri-opensuse/commit/443a07e95468e2166ad333898486ed4c7711689a by [Joaqu�n Rivera](https://github.com/jknphy) but certainly that can still be changed to record another workaround