On Thu, Apr 07, 2016 at 04:21:53PM +0800, Qu Wenruo wrote:
> I ran into one soft lockup with my patch only. So I assume it's not
> caused by your inherit patch though.
> But I didn't reproduce it once more. Not sure why.
>
> What's the reproduce rate in your environment?
It happens every time
Hi Mark,
Thanks for the test and reporting.
Mark Fasheh wrote on 2016/04/06 19:43 -0700:
Hi Qu,
On Wed, Apr 06, 2016 at 10:04:54AM +0800, Qu Wenruo wrote:
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Hi Qu,
On Wed, Apr 06, 2016 at 10:04:54AM +0800, Qu Wenruo wrote:
> Current btrfs qgroup design implies a requirement that after calling
> btrfs_qgroup_account_extents() there must be a commit root switch.
>
> Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
> inside
Filipe Manana wrote on 2016/04/06 10:20 +0100:
On Wed, Apr 6, 2016 at 3:04 AM, Qu Wenruo wrote:
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as
On Wed, Apr 6, 2016 at 3:04 AM, Qu Wenruo wrote:
> Current btrfs qgroup design implies a requirement that after calling
> btrfs_qgroup_account_extents() there must be a commit root switch.
>
> Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
>
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a