Hi David,
This is the reminder of how we could handle the behavior change of
staled qgroup auto removal.
[PROBLEM]
If btrfs has dropped one subvolume, it will not delete the level 0
qgroup automatically, leaving the qgroup still hanging there, with all
numbers set to 0.
This needs manual user interaction to delete all those staled qgroups.
[SOLUTIONS]
There are several way to solve it, all with its advantage and disadvantage.
- Auto remove them by default, and no way to keep the the staled qgroups
Pro: Easy to implement (already submitted)
Con: User has no choice to keep staled qgroups. But I could argue that
no one sane would want to keep them anyway.
- Mount option `qg_auto_remove`
Pro: Still easy to implement, and users can have their choice
Con: Mount options are never a good nor extendable solution, not to
mention there are tons of users who will never user qgroup.
Introducing a default mount option for users who will never use
qgroup doesn't look good to me.
- New qgroup status flag (QGROUP_STATUS_FLAG_AUTO_REMOVE)
Pro: Only affects qgroup, users can have their choice
Con: More complex to implement, needs both btrfs-progs and kernel
change, and even change the ioctl interface, as we don't have
method to pass extra flags to btrfs_quota_enable().
I strongly doubt if such hassle is really needed if no one wants
staled qgroup.
One of the biggest concern is, is there any user cares about the staled
qgroups? Their numbers are all 0, and doesn't affect anything.
The only impact is, users need to delete them manually.
Thus except back-compatible issue, I see no reason to allow user to keep
staled qgroups.
Anyway you have the final call, I just hope we won't leave some complex
mechanism and let later developers to wonder why all this hassle is needed.
Thanks,
Qu
Attachment:
signature.asc
Description: OpenPGP digital signature
