From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Sargun Dhillon <sargun@sargun.me>,
BTRFS ML <linux-btrfs@vger.kernel.org>
Subject: Re: QGroups Semantics
Date: Mon, 22 May 2017 08:59:13 +0800 [thread overview]
Message-ID: <c2e1824a-b395-53da-8cd2-cade09449313@cn.fujitsu.com> (raw)
In-Reply-To: <CAMp4zn8CfdzPn7UAHf7S2PT1F8ysf95jMi7F8RBUuyBvqYT5xw@mail.gmail.com>
At 05/19/2017 05:07 PM, Sargun Dhillon wrote:
> I have some questions about the *intended* qgroups semantics, and why
> we allow certain operations:
>
> 1) Why can you create a level 0 qgroup for a non-existent subvolume?
> It looks like it just gets reset when you create the subvol anyway?
> Should we prevent this?
Personally speaking, I didn't see much meaning of allowing this, except
setting limit before creating the subvolume.
But that can also be done by setting up higher level qgroup and attach
new subvolume to that higher level qgroup.
IIRC there are some guys hoping to disable multi-level qgroup
completely, if one day we decide to do that, then current behavior may
be quite important.
>
> 2) Why do we allow deleting a level 0 qgroup for a currently existing
> subvolume? It seems to me that just setting the limit to 0, and/or
> removing relations would work equally well? Perhaps a new ioctl to
> clear the qgroup would make sense to do this.
At least I didn't see the meaning to allow deleting qgroup for existing
subvolume.
It won't even improve any performance since we still need to do the time
consuming backref walk.
>
> 3) Why don't we remove the associated level 0 qgroup when you remove
> the subvol with that id?
This may be related to question 1).
Sometimes we may want to keep the limit?
Despite of that, I didn't see any reason to keep the orphan level 0 qgroup.
>
> 4) I noticed in qgroup.c, one of the outstanding items is to determine
> how to autocleanup. Are there any stated semantics around that, or
> opinions?
As long as we're going to stick with multi level qgroups, then
autocleanup seems to be a good idea.
Thanks,
Qu
>
> PS:
> If the answer to any of these is "it just needs to be worked on" --
> I'm currently poking around this code path for some enhancements we're
> doing for our usecase. I'm just trying to figure out how much of what
> I'm doing is generalizable.
>
> -Thanks,
> Sargun
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
next prev parent reply other threads:[~2017-05-22 0:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-19 9:07 QGroups Semantics Sargun Dhillon
2017-05-22 0:59 ` Qu Wenruo [this message]
2017-05-22 20:54 ` Sargun Dhillon
2017-05-23 1:23 ` Qu Wenruo
2017-05-23 5:38 ` Marat Khalili
2017-05-23 7:38 ` Marat Khalili
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=c2e1824a-b395-53da-8cd2-cade09449313@cn.fujitsu.com \
--to=quwenruo@cn.fujitsu.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=sargun@sargun.me \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.