About stale qgroup auto removal behavior change

About stale qgroup auto removal behavior change

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 1916 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: About stale qgroup auto removal behavior change

[Josef Bacik]

On 2/3/20 7:37 PM, Qu Wenruo wrote:
> 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.

This should have been what was done in the first place.  Nobody is using qgroups 
right now anyway as they do not work, might as well do it the correct way now so 
when they are in use we don't have to worry about it.  Thanks,

Josef

Re: About stale qgroup auto removal behavior change

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 1190 bytes --]



On 2020/2/5 上午2:20, Josef Bacik wrote:
> On 2/3/20 7:37 PM, Qu Wenruo wrote:
>> 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.
> 
> This should have been what was done in the first place.  Nobody is using
> qgroups right now anyway as they do not work, might as well do it the
> correct way now so when they are in use we don't have to worry about
> it.  Thanks,
> 
> Josef
David, what's your idea?
Still want to push the enable ioctl way?

Thanks,
Qu


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]