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

[Wang Shilong]

From: Wang Shilong wangsl-f...@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/2570/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-f...@cn.fujitsu.com
Acked-by: Miao Xie mi...@cn.fujitsu.com
Cc: Arne Jansen sensi...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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-f...@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/2570/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-f...@cn.fujitsu.com
 Acked-by: Miao Xie mi...@cn.fujitsu.com
 Cc: Arne Jansen sensi...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Shilong Wang]

Hello,

2013/2/22 Arne Jansen sensi...@gmx.net:
 On 02/22/13 13:09, Wang Shilong wrote:
 From: Wang Shilong wangsl-f...@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/2570/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-f...@cn.fujitsu.com
 Acked-by: Miao Xie mi...@cn.fujitsu.com
 Cc: Arne Jansen sensi...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 sensi...@gmx.net:
  On 02/22/13 13:09, Wang Shilong wrote:
  From: Wang Shilong wangsl-f...@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/2570/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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Shilong Wang]

Hello, David

2013/2/23 David Sterba dste...@suse.cz:
 On Sat, Feb 23, 2013 at 12:39:24AM +0800, Shilong Wang wrote:
 Hello,

 2013/2/22 Arne Jansen sensi...@gmx.net:
  On 02/22/13 13:09, Wang Shilong wrote:
  From: Wang Shilong wangsl-f...@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/2570/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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html