From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: David Sterba <dsterba@suse.cz>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: About stale qgroup auto removal behavior change
Date: Tue, 4 Feb 2020 08:37:14 +0800 [thread overview]
Message-ID: <2dfbf017-9c82-1224-bdfc-73d0c0111e40@gmx.com> (raw)
[-- 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 --]
next reply other threads:[~2020-02-04 0:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-04 0:37 Qu Wenruo [this message]
2020-02-04 18:20 ` About stale qgroup auto removal behavior change Josef Bacik
2020-02-05 1:00 ` Qu Wenruo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2dfbf017-9c82-1224-bdfc-73d0c0111e40@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox