Hi Alin,
On 11/28/2013 06:01 PM, Alin Dobre wrote:
It seems that the problem was that we didn't delete the corresponding
qgroup when deleting the subvolume, which was filling the metadata
with unused information. Removing all the stale qgroups fixes the
problem and allows subsequent subvolume creation without any quota
disable/enable action. Also, we are now automatically deleting the
corresponding qgroup after the subvolume is removed.
Until now, we won't delete subvolume's corresponding qgroup
automactiallly yet. The main reason is:
Deleting subvolume is 'async', we still need to make qgroup accounting
correct(differ 'rfer' and 'excl').
In theory, we can only remove a qgroup safely when it's referenced goes
0. This is the main reason
why we don't delete subvolume qgroup directly.
And the point is deleting subvolume won't walk the whole fs tree, and
qgroup is dependent on this,
now, deleting subvolume may break qgroup accounting.(though qgroup
rescan can make it right, we
can not rely on this so much).
Anyway, though we don't remove qgroup automactially, it should not
affect subvolume creation
This is because qgroup is corresponding subvolume, it will not be resued
since subvolumeid
is although going larger.
Thanks,
Wang
Cheers,
Alin.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
