public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
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 --]

             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