Just some user's point of view:
I propose the following changes:
1) We always cleanup level-0 qgroups by default, with no opt-out.
I see absolutely no reason to keep these around.
It WILL break scripts that try to do this cleanup themselves. OTOH it
will simplify writing new ones.
Since qgroups are assigned sequential numbers, it must be possible to
partially work it around by not returning error on repeated delete. But
you cannot completely emulate qgroup presence without actually keeping
it, so some scripts will still break.
More complete workaround would be delayed cleanup. What about (re-)mount
time? (Should also handle qgroups remaining )
We do not allow the creation of level-0 qgroups for (sub)volumes
that do not exist.
Probably I'm mistaken, but I see no reasons for doing it even now, since
I don't think it's possible to reliably assign existing 0-level qgroup
to a new subvolume. So this change should break nothing.
Why do we allow deleting a level 0 qgroup for a currently existing
subvolume?
4) Add a flag to the qgroup_delete_v2 ioctl, NO_SUBVOL_CHECK.
If the flag is present, it will allow you to delete qgroups which
reference active subvolumes.
Some people doing cleanup in the reverse order? Other than this, I don't
understand why this feature is needed, so IMO it's unlikely to be needed
in a new API.
Of course, this is all just one datapoint for you.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
