On 2018/8/15 下午9:06, David Sterba wrote: > On Thu, Aug 09, 2018 at 04:05:36PM +0900, Misono Tomohiro wrote: >> When qgroup is on, subvolume deletion does not remove qgroup items >> of the subvolume (qgroup info, limit, relation) from quota tree and >> they need to get removed manually by "btrfs qgroup destroy". >> >> Since level 0 qgroup cannot be used/inherited by any other subvolume, >> let's remove them automatically when subvolume is deleted >> (to be precise, when the subvolume root is dropped). > > Please note that dropping the 0-level qgroup has user-visible impact > that needs to be evaluated.
I wonder if this is the case. Normal btrfs subvolume creation using the highest objectid available in root tree, thus later subvolume won't take the id of the to-be-deleted subvolume. Further more, this auto-removal only happens when the to-be-deleted subvolume get completely removed, thus there should be no way to access the subvolume already before we hit the branch in this patch. So yes, the level 0 qgroup auto-removal is bringing a user visible change, but user can't do anything anyway, and the result should just save some "btrfs qgroup destroy/remove" calls. Or did I miss something? Thanks, Qu > I don't see anything like that in the > changelog. > If there's a potential or actual breakage after this patch, > it needs to be addressed in some way. > > This is not the first time somebody proposes to do the auto deletion. > While I'm not against it, it still has to be done the right way. > Anything that touches user interfaces must get extra care, and review > bandwidth for that is unfortunatelly extra low. I can't give you an ETA > or merge target for this patch. >
signature.asc
Description: OpenPGP digital signature
