[RESEND RFC PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use

[RESEND RFC PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use

[Wang Shilong]

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

Re: [RESEND RFC PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use

[Arne Jansen]

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;
>  	}
> 

Re: [RESEND RFC PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use

[Shilong Wang]

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;
>>       }
>>
>

Re: [RESEND RFC PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use

[David Sterba]

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

Re: [RESEND RFC PATCH 2/2] Btrfs: disable the qgroup level 0 for userspace use

[Shilong Wang]

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