Wang Shilong
2013-Feb-22 12:09 UTC
[RESEND RFC PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use
From: Wang Shilong <wangsl-fnst@cn.fujitsu.com>
This patch tries to stop users to create/destroy qgroup level 0,
users can only create/destroy qgroup level more than 0.
See the fact:
a subvolume/snapshot qgroup was created automatically
when creating subvolume/snapshot, so creating a qgroup level 0 can''t
be a subvolume/snapshot qgroup, the only way to use it is that assigning
subvolume/snapshot qgroup to it, the point is that we don''t want to
have a
parent qgroup whose level is 0.
So we want to force users to use qgroup with clear relations
which means a parent qgroup''s level > child qgroup''s
level.For example:
2/0
/ \
/ \
/ \
1/0 1/1
/ \ \
/ \ \
/ \ \
0/256 0/257 0/258
This pattern of quota is nature and easy for users to understand, otherwise it
will
make the quota configuration confusing and difficult to maintain.
Signed-off-by: Wang Shilong <wangsl-fnst@cn.fujitsu.com>
Acked-by: Miao Xie <miaox@cn.fujitsu.com>
Cc: Arne Jansen <sensille@gmx.net>
---
fs/btrfs/ioctl.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index a31cd93..3590c21 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -3755,7 +3755,7 @@ static long btrfs_ioctl_qgroup_create(struct file *file,
void __user *arg)
goto drop_write;
}
- if (!sa->qgroupid) {
+ if (!(sa->qgroupid >> 48)) {
ret = -EINVAL;
goto out;
}
--
1.7.7.6
--
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
Arne Jansen
2013-Feb-22 13:35 UTC
Re: [RESEND RFC PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use
On 02/22/13 13:09, Wang Shilong wrote:> From: Wang Shilong <wangsl-fnst@cn.fujitsu.com> > > This patch tries to stop users to create/destroy qgroup level 0, > users can only create/destroy qgroup level more than 0. > > See the fact: > a subvolume/snapshot qgroup was created automatically > when creating subvolume/snapshot, so creating a qgroup level 0 can''t > be a subvolume/snapshot qgroup, the only way to use it is that assigning > subvolume/snapshot qgroup to it, the point is that we don''t want to have a > parent qgroup whose level is 0. > > So we want to force users to use qgroup with clear relations > which means a parent qgroup''s level > child qgroup''s level.For example: > > 2/0 > / \ > / \ > / \ > 1/0 1/1 > / \ \ > / \ \ > / \ \ > 0/256 0/257 0/258 > > This pattern of quota is nature and easy for users to understand, otherwise it will > make the quota configuration confusing and difficult to maintain.I agree that a strict hierarchy of the levels should be enforced. Currently the kernel has no idea of ''level'', it''s just an artificial concept that lives in userspace. This patch would be the first place to add that magic shift ''48'' to the kernel. In my opinion it would be sufficient to do the enforcement in user space, as it is of no technical nature. -Arne> > Signed-off-by: Wang Shilong <wangsl-fnst@cn.fujitsu.com> > Acked-by: Miao Xie <miaox@cn.fujitsu.com> > Cc: Arne Jansen <sensille@gmx.net> > --- > fs/btrfs/ioctl.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c > index a31cd93..3590c21 100644 > --- a/fs/btrfs/ioctl.c > +++ b/fs/btrfs/ioctl.c > @@ -3755,7 +3755,7 @@ static long btrfs_ioctl_qgroup_create(struct file *file, void __user *arg) > goto drop_write; > } > > - if (!sa->qgroupid) { > + if (!(sa->qgroupid >> 48)) { > ret = -EINVAL; > goto out; > } >-- 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
Shilong Wang
2013-Feb-22 16:39 UTC
Re: [RESEND RFC PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use
Hello, 2013/2/22 Arne Jansen <sensille@gmx.net>:> On 02/22/13 13:09, Wang Shilong wrote: >> From: Wang Shilong <wangsl-fnst@cn.fujitsu.com> >> >> This patch tries to stop users to create/destroy qgroup level 0, >> users can only create/destroy qgroup level more than 0. >> >> See the fact: >> a subvolume/snapshot qgroup was created automatically >> when creating subvolume/snapshot, so creating a qgroup level 0 can''t >> be a subvolume/snapshot qgroup, the only way to use it is that assigning >> subvolume/snapshot qgroup to it, the point is that we don''t want to have a >> parent qgroup whose level is 0. >> >> So we want to force users to use qgroup with clear relations >> which means a parent qgroup''s level > child qgroup''s level.For example: >> >> 2/0 >> / \ >> / \ >> / \ >> 1/0 1/1 >> / \ \ >> / \ \ >> / \ \ >> 0/256 0/257 0/258 >> >> This pattern of quota is nature and easy for users to understand, otherwise it will >> make the quota configuration confusing and difficult to maintain. > > I agree that a strict hierarchy of the levels should be enforced. > Currently the kernel has no idea of ''level'', it''s just an artificial > concept that lives in userspace. This patch would be the first place > to add that magic shift ''48'' to the kernel. > In my opinion it would be sufficient to do the enforcement in user > space, as it is of no technical nature. >...i have made some patches about these work in btrfs-prog, but it has been not merged... I will pick up thoses patches and do the other necessary work.. Thanks, Wang> -Arne > >> >> Signed-off-by: Wang Shilong <wangsl-fnst@cn.fujitsu.com> >> Acked-by: Miao Xie <miaox@cn.fujitsu.com> >> Cc: Arne Jansen <sensille@gmx.net> >> --- >> fs/btrfs/ioctl.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c >> index a31cd93..3590c21 100644 >> --- a/fs/btrfs/ioctl.c >> +++ b/fs/btrfs/ioctl.c >> @@ -3755,7 +3755,7 @@ static long btrfs_ioctl_qgroup_create(struct file *file, void __user *arg) >> goto drop_write; >> } >> >> - if (!sa->qgroupid) { >> + if (!(sa->qgroupid >> 48)) { >> ret = -EINVAL; >> goto out; >> } >> >-- 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
David Sterba
2013-Feb-22 22:35 UTC
Re: [RESEND RFC PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use
On Sat, Feb 23, 2013 at 12:39:24AM +0800, Shilong Wang wrote:> Hello, > > 2013/2/22 Arne Jansen <sensille@gmx.net>: > > On 02/22/13 13:09, Wang Shilong wrote: > >> From: Wang Shilong <wangsl-fnst@cn.fujitsu.com> > >> > >> This patch tries to stop users to create/destroy qgroup level 0, > >> users can only create/destroy qgroup level more than 0. > >> > >> See the fact: > >> a subvolume/snapshot qgroup was created automatically > >> when creating subvolume/snapshot, so creating a qgroup level 0 can''t > >> be a subvolume/snapshot qgroup, the only way to use it is that assigning > >> subvolume/snapshot qgroup to it, the point is that we don''t want to have a > >> parent qgroup whose level is 0. > >> > >> So we want to force users to use qgroup with clear relations > >> which means a parent qgroup''s level > child qgroup''s level.For example: > >> > >> 2/0 > >> / \ > >> / \ > >> / \ > >> 1/0 1/1 > >> / \ \ > >> / \ \ > >> / \ \ > >> 0/256 0/257 0/258 > >> > >> This pattern of quota is nature and easy for users to understand, otherwise it will > >> make the quota configuration confusing and difficult to maintain. > > > > I agree that a strict hierarchy of the levels should be enforced. > > Currently the kernel has no idea of ''level'', it''s just an artificial > > concept that lives in userspace. This patch would be the first place > > to add that magic shift ''48'' to the kernel. > > In my opinion it would be sufficient to do the enforcement in user > > space, as it is of no technical nature. > > > > ...i have made some patches about these work in btrfs-prog, but it has > been not merged... > I will pick up thoses patches and do the other necessary work..This one? https://patchwork.kernel.org/patch/2008591/ went through integration branch into progs'' master. david -- 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
Shilong Wang
2013-Feb-23 02:10 UTC
Re: [RESEND RFC PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use
Hello, David 2013/2/23 David Sterba <dsterba@suse.cz>:> On Sat, Feb 23, 2013 at 12:39:24AM +0800, Shilong Wang wrote: >> Hello, >> >> 2013/2/22 Arne Jansen <sensille@gmx.net>: >> > On 02/22/13 13:09, Wang Shilong wrote: >> >> From: Wang Shilong <wangsl-fnst@cn.fujitsu.com> >> >> >> >> This patch tries to stop users to create/destroy qgroup level 0, >> >> users can only create/destroy qgroup level more than 0. >> >> >> >> See the fact: >> >> a subvolume/snapshot qgroup was created automatically >> >> when creating subvolume/snapshot, so creating a qgroup level 0 can''t >> >> be a subvolume/snapshot qgroup, the only way to use it is that assigning >> >> subvolume/snapshot qgroup to it, the point is that we don''t want to have a >> >> parent qgroup whose level is 0. >> >> >> >> So we want to force users to use qgroup with clear relations >> >> which means a parent qgroup''s level > child qgroup''s level.For example: >> >> >> >> 2/0 >> >> / \ >> >> / \ >> >> / \ >> >> 1/0 1/1 >> >> / \ \ >> >> / \ \ >> >> / \ \ >> >> 0/256 0/257 0/258 >> >> >> >> This pattern of quota is nature and easy for users to understand, otherwise it will >> >> make the quota configuration confusing and difficult to maintain. >> > >> > I agree that a strict hierarchy of the levels should be enforced. >> > Currently the kernel has no idea of ''level'', it''s just an artificial >> > concept that lives in userspace. This patch would be the first place >> > to add that magic shift ''48'' to the kernel. >> > In my opinion it would be sufficient to do the enforcement in user >> > space, as it is of no technical nature. >> > >> >> ...i have made some patches about these work in btrfs-prog, but it has >> been not merged... >> I will pick up thoses patches and do the other necessary work.. > > This one? > > https://patchwork.kernel.org/patch/2008591/ > > went through integration branch into progs'' master.Yes, it is.However, more work needs done to make it work well.. I''d continue my work based on integration-20130126.. Thanks, Wang> david-- 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