Btrfs devel - Jul 2013 - btrfs qgroup assign -> "ERROR: bad relation requested"

I''m trying to use this feature of qgroup:

btrfs qgroup assign <srcid> <destid> <path>
    Assigns the lower level qgroup src to the higher level qgroup dest
    in the btrfs found in <path>. It is used to build qgroup
    hierarchies.


However, I fail to understand how this feature should work, and I''m
getting "ERROR: bad relation requested":

# btrfs sub create test1
Create subvolume ''./test1''

# btrfs sub create test2
Create subvolume ''./test2''

# btrfs sub list /mnt/lxc2 | grep test
ID 1177 gen 85131 top level 5 path test1
ID 1178 gen 85132 top level 5 path test2

# btrfs qgroup show /mnt/lxc2
0/1177 4096 4096
0/1178 4096 4096

# btrfs qgroup assign 1177 1178 /mnt/lx2
ERROR: bad relation requested ''/mnt/lx2''


Could anyone give examples of proper usage of this feature?

This is Linux 3.10.


-- 
Tomasz Chmielewski
http://wpkg.org
--
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

Hello,
> I''m trying to use this feature of qgroup:
> 
> btrfs qgroup assign <srcid> <destid> <path>
>    Assigns the lower level qgroup src to the higher level qgroup dest
>    in the btrfs found in <path>. It is used to build qgroup
>    hierarchies.
> 
> 
> However, I fail to understand how this feature should work, and
I''m
> getting "ERROR: bad relation requested":
> 
> # btrfs sub create test1
> Create subvolume ''./test1''
> 
> # btrfs sub create test2
> Create subvolume ''./test2''
> 
> # btrfs sub list /mnt/lxc2 | grep test
> ID 1177 gen 85131 top level 5 path test1
> ID 1178 gen 85132 top level 5 path test2
> 
> # btrfs qgroup show /mnt/lxc2
> 0/1177 4096 4096
> 0/1178 4096 4096
> 
> # btrfs qgroup assign 1177 1178 /mnt/lx2
> ERROR: bad relation requested ''/mnt/lx2''
> 
> 
> Could anyone give examples of proper usage of this feature?
> 
Now qgroup require strict hierarchy. Every qgroup can be divided into
two parts:
		<level>/id

Btrfs group assign requires parent''s level > children''s
level, For your example
below, you can do like:

btrfs qgroup create 1/1 <mnt>
btrfs qgroup assign  1177 1/1 <mnt>
btrfs qgroup assign  1178 1/1  <mnt>

And if you want to limit subvol(1177), you can do

btrfs qgroup limit  size 1177 <mnt>

Also, if you want to limit total size of 1177 and 1178, you
can set limit on qgroup 1/1.

Thanks,
Wang
> This is Linux 3.10.m
> 
> 
> -- 
> Tomasz Chmielewski
> http://wpkg.org
> --
> 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
--
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

On Sun, 28 Jul 2013 15:36:41 +0800
Wang Shilong <wangshilong1991@gmail.com> wrote:
> Btrfs group assign requires parent''s level >
children''s level, For
> your example below, you can do like:
> 
> btrfs qgroup create 1/1 <mnt>
> btrfs qgroup assign  1177 1/1 <mnt>
> btrfs qgroup assign  1178 1/1  <mnt>
Cool, thanks.

And is it possible (i.e. at some later point) to verify that 1177, 1178
were assigned to 1/1 (or in general, what is assigned to 1/1)?


-- 
Tomasz Chmielewski
http://wpkg.org

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

Hello,
> On Sun, 28 Jul 2013 15:36:41 +0800
> Wang Shilong <wangshilong1991@gmail.com> wrote:
> 
>> Btrfs group assign requires parent''s level >
children''s level, For
>> your example below, you can do like:
>> 
>> btrfs qgroup create 1/1 <mnt>
>> btrfs qgroup assign  1177 1/1 <mnt>
>> btrfs qgroup assign  1178 1/1  <mnt>
> 
> Cool, thanks.
> 
> And is it possible (i.e. at some later point) to verify that 1177, 1178
> were assigned to 1/1 (or in general, what is assigned to 1/1)?
I have implemented the above function, but they haven''t gone into
upstream
Btrfs-progs.

You can try this:

	http://github.com/miaoxie/btrfs-progs.git qgroup

Maybe i need rebase the patch-set later, But you can try it firstly, if you want
to see
every qgroup''s parent, you can add option ''-p'':

btrfs qgroup show  -p <mnt>


If you want to see what is assigned to 1/1, you can use:

btrfs group show -c <mnt>

Further, if you want to see a specified path''s parent qgroup, you can
use it:

btrfs group show -F/-f <path>

Also ''-l'' and ''-e'' print limit size of
qgroup.

Thanks,
Wang
> 
>  
> -- 
> Tomasz Chmielewski
> http://wpkg.org
> 
--
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

On Tue, 30 Jul 2013 21:06:32 +0800
Wang Shilong <wangshilong1991@gmail.com> wrote:
> I have implemented the above function, but they haven''t gone into
> upstream Btrfs-progs.
> 
> You can try this:
> 
> 	http://github.com/miaoxie/btrfs-progs.git qgroup
> 
> Maybe i need rebase the patch-set later, But you can try it firstly,
> if you want to see every qgroup''s parent, you can add option
''-p'':
> 
> btrfs qgroup show  -p <mnt>
Hmm, is it correct git URL?

# btrfs qgroup show -p /mnt/lxc2
btrfs qgroup show: too many arguments
usage: btrfs qgroup show <path>

    Show all subvolume quota groups.



-- 
Tomasz Chmielewski
http://wpkg.org
--
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

On 07/31/2013 11:46 AM, Tomasz Chmielewski wrote:
> On Tue, 30 Jul 2013 21:06:32 +0800
> Wang Shilong <wangshilong1991@gmail.com> wrote:
> 
>> I have implemented the above function, but they haven''t gone
into
>> upstream Btrfs-progs.
>>
>> You can try this:
>>
>> 	http://github.com/miaoxie/btrfs-progs.git qgroup
>>
>> Maybe i need rebase the patch-set later, But you can try it firstly,
>> if you want to see every qgroup''s parent, you can add option
''-p'':
>>
>> btrfs qgroup show  -p <mnt>
> 
> Hmm, is it correct git URL?

I have tried it and it works, you can do like the following to try it.

#git clone http://github.com/miaoxie/btrfs-progs.git

#cd btrfs-progs

#git pull origin master

#make && make install

Thanks,
Wang
> 
> # btrfs qgroup show -p /mnt/lxc2
> btrfs qgroup show: too many arguments
> usage: btrfs qgroup show <path>
> 
>     Show all subvolume quota groups.
> 
> 
> 
--
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

On Wed, 31 Jul 2013 12:19:36 +0800
Wang Shilong <wangsl.fnst@cn.fujitsu.com> wrote:
> I have tried it and it works, you can do like the following to try it.
> 
> #git clone http://github.com/miaoxie/btrfs-progs.git
> 
> #cd btrfs-progs
> 
> #git pull origin master
> 
> #make && make install
Hmm:

# git clone http://github.com/miaoxie/btrfs-progs.git
Cloning into ''btrfs-progs''...
remote: Counting objects: 3917, done.
remote: Compressing objects: 100% (1565/1565), done.
remote: Total 3917 (delta 2681), reused 3582 (delta 2348)
Receiving objects: 100% (3917/3917), 1.88 MiB | 634 KiB/s, done.
Resolving deltas: 100% (2681/2681), done.

# cd btrfs-progs/

# git pull origin master
From http://github.com/miaoxie/btrfs-progs
 * branch            master     -> FETCH_HEAD
Already up-to-date.

# make && make install
(...)

# btrfs qgroup show -p /mnt/lxc2
btrfs qgroup show: too many arguments
usage: btrfs qgroup show <path>

    Show all subvolume quota groups.



This is the right binary (by looking at timestamps):

# /usr/local/bin/btrfs qgroup show -p /mnt/lxc2
btrfs qgroup show: too many arguments
usage: btrfs qgroup show <path>

    Show all subvolume quota groups.

# ls -l /usr/local/bin/btrfs
-rwxr-xr-x 1 root staff 1.5M Jul 31 04:30 /usr/local/bin/btrfs

# date
Wed Jul 31 04:33:59 UTC 2013


"git log" is quite old, too (last change from Thu Nov 8 17:54:13 2012
+0800).


-- 
Tomasz Chmielewski
http://wpkg.org
--
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

On 07/31/2013 12:36 PM, Tomasz Chmielewski wrote:
> On Wed, 31 Jul 2013 12:19:36 +0800
> Wang Shilong <wangsl.fnst@cn.fujitsu.com> wrote:
> 
>> I have tried it and it works, you can do like the following to try it.
>>
>> #git clone http://github.com/miaoxie/btrfs-progs.git
>>
>> #cd btrfs-progs
>>
>> #git pull origin master
>>
>> #make && make install
> 
> Hmm:
> 
> # git clone http://github.com/miaoxie/btrfs-progs.git
> Cloning into ''btrfs-progs''...
> remote: Counting objects: 3917, done.
> remote: Compressing objects: 100% (1565/1565), done.
> remote: Total 3917 (delta 2681), reused 3582 (delta 2348)
> Receiving objects: 100% (3917/3917), 1.88 MiB | 634 KiB/s, done.
> Resolving deltas: 100% (2681/2681), done.
> 
> # cd btrfs-progs/
> 
> # git pull origin master
Oops, i am sorry, here should:

git pull origin qgroup

would you please try it again
>>From http://github.com/miaoxie/btrfs-progs
>  * branch            master     -> FETCH_HEAD
> Already up-to-date.
> 
> # make && make install
> (...)
> 
> # btrfs qgroup show -p /mnt/lxc2
> btrfs qgroup show: too many arguments
> usage: btrfs qgroup show <path>
> 
>     Show all subvolume quota groups.
> 
> 
> 
> This is the right binary (by looking at timestamps):
> 
> # /usr/local/bin/btrfs qgroup show -p /mnt/lxc2
> btrfs qgroup show: too many arguments
> usage: btrfs qgroup show <path>
> 
>     Show all subvolume quota groups.
> 
> # ls -l /usr/local/bin/btrfs
> -rwxr-xr-x 1 root staff 1.5M Jul 31 04:30 /usr/local/bin/btrfs
> 
> # date
> Wed Jul 31 04:33:59 UTC 2013
> 
> 
> "git log" is quite old, too (last change from Thu Nov 8 17:54:13
2012 +0800).
Yeah, it is old, i need rebase my patch-set on the latest btrfs-progs.

Thanks,
Wang
> 
> 
--
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

On Wed, 31 Jul 2013 13:13:37 +0800
Wang Shilong <wangsl.fnst@cn.fujitsu.com> wrote:
> > # git pull origin master
> 
> Oops, i am sorry, here should:
> 
> git pull origin qgroup
> 
> would you please try it again
Excellent, it works:

# btrfs qgroup show -p /mnt/lxc2
0/260 154273873920 154273873920 ---
0/261 181260288 181260288 ---
0/262 155557888 983040 ---
0/377 180539392 26005504 ---
0/378 308607238144 308607238144 ---
0/535 572407808 417832960 ---
0/536 68085026816 68085026816 ---
0/642 247824384 93282304 ---
0/1276 636026880 4096 1/1
0/1277 38301687808 4096 1/1
0/1278 617164800 32768 1/1
0/1279 38297591808 4096 1/1
0/1284 38299160576 0 1/1
0/1285 38299160576 21364736 1/1
0/1286 620396544 0 1/1
0/1287 633090048 12722176 1/1
0/1293 38301687808 4096 1/1
0/1294 636026880 4096 1/1
1/1 38972137472 38972137472 ---


Thanks a lot!


Am I correct to think that I have to run quota rescan after
assigning groups?

# btrfs qgroup assign 378 1/1 /mnt/lxc2  <<----- assigning volid 378,
having 300+ GB

# btrfs qgroup show -p /mnt/lxc2 | grep 1/1
0/378 308607238144 308607238144 1/1
0/1276 636026880 4096 1/1
0/1277 38301687808 4096 1/1
0/1278 617164800 32768 1/1
0/1279 38297591808 4096 1/1
0/1284 38299160576 0 1/1
0/1285 38299160576 21364736 1/1
0/1286 620396544 0 1/1
0/1287 633090048 12722176 1/1
0/1293 38301687808 4096 1/1
0/1294 636026880 4096 1/1
1/1 38972137472 38972137472 ---  <<----- although we''ve added
300+ GB volume, the total numbers are unchanged


That can be quite a bit of IO?


-- 
Tomasz Chmielewski
http://wpkg.org
--
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

Hello,

On 07/31/2013 01:39 PM, Tomasz Chmielewski wrote:
> On Wed, 31 Jul 2013 13:13:37 +0800
> Wang Shilong <wangsl.fnst@cn.fujitsu.com> wrote:
> 
>>> # git pull origin master
>>
>> Oops, i am sorry, here should:
>>
>> git pull origin qgroup
>>
>> would you please try it again
> 
> Excellent, it works:
> 
> # btrfs qgroup show -p /mnt/lxc2
> 0/260 154273873920 154273873920 ---
> 0/261 181260288 181260288 ---
> 0/262 155557888 983040 ---
> 0/377 180539392 26005504 ---
> 0/378 308607238144 308607238144 ---
> 0/535 572407808 417832960 ---
> 0/536 68085026816 68085026816 ---
> 0/642 247824384 93282304 ---
> 0/1276 636026880 4096 1/1
> 0/1277 38301687808 4096 1/1
> 0/1278 617164800 32768 1/1
> 0/1279 38297591808 4096 1/1
> 0/1284 38299160576 0 1/1
> 0/1285 38299160576 21364736 1/1
> 0/1286 620396544 0 1/1
> 0/1287 633090048 12722176 1/1
> 0/1293 38301687808 4096 1/1
> 0/1294 636026880 4096 1/1
> 1/1 38972137472 38972137472 ---
> 
> 
> Thanks a lot!
> 
> 
> Am I correct to think that I have to run quota rescan after
> assigning groups?
> 
> # btrfs qgroup assign 378 1/1 /mnt/lxc2  <<----- assigning volid 378,
having 300+ GB
Until now, Yes, we have to recan to correct qgroup accounting.
> 
> # btrfs qgroup show -p /mnt/lxc2 | grep 1/1
> 0/378 308607238144 308607238144 1/1
> 0/1276 636026880 4096 1/1
> 0/1277 38301687808 4096 1/1
> 0/1278 617164800 32768 1/1
> 0/1279 38297591808 4096 1/1
> 0/1284 38299160576 0 1/1
> 0/1285 38299160576 21364736 1/1
> 0/1286 620396544 0 1/1
> 0/1287 633090048 12722176 1/1
> 0/1293 38301687808 4096 1/1
> 0/1294 636026880 4096 1/1
> 1/1 38972137472 38972137472 ---  <<----- although we''ve
added 300+ GB volume, the total numbers are unchanged
> 
> 
> That can be quite a bit of IO?
> 
> 
--
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

On 07/31/13 07:39, Tomasz Chmielewski wrote:
> On Wed, 31 Jul 2013 13:13:37 +0800
> Wang Shilong <wangsl.fnst@cn.fujitsu.com> wrote:
> 
>>> # git pull origin master
>>
>> Oops, i am sorry, here should:
>>
>> git pull origin qgroup
>>
>> would you please try it again
> 
> Excellent, it works:
> 
> # btrfs qgroup show -p /mnt/lxc2
> 0/260 154273873920 154273873920 ---
> 0/261 181260288 181260288 ---
> 0/262 155557888 983040 ---
> 0/377 180539392 26005504 ---
> 0/378 308607238144 308607238144 ---
> 0/535 572407808 417832960 ---
> 0/536 68085026816 68085026816 ---
> 0/642 247824384 93282304 ---
> 0/1276 636026880 4096 1/1
> 0/1277 38301687808 4096 1/1
> 0/1278 617164800 32768 1/1
> 0/1279 38297591808 4096 1/1
> 0/1284 38299160576 0 1/1
> 0/1285 38299160576 21364736 1/1
> 0/1286 620396544 0 1/1
> 0/1287 633090048 12722176 1/1
> 0/1293 38301687808 4096 1/1
> 0/1294 636026880 4096 1/1
> 1/1 38972137472 38972137472 ---
> 
> 
> Thanks a lot!
> 
> 
> Am I correct to think that I have to run quota rescan after
> assigning groups?
> 
> # btrfs qgroup assign 378 1/1 /mnt/lxc2  <<----- assigning volid 378,
having 300+ GB
> 
> # btrfs qgroup show -p /mnt/lxc2 | grep 1/1
> 0/378 308607238144 308607238144 1/1
> 0/1276 636026880 4096 1/1
> 0/1277 38301687808 4096 1/1
> 0/1278 617164800 32768 1/1
> 0/1279 38297591808 4096 1/1
> 0/1284 38299160576 0 1/1
> 0/1285 38299160576 21364736 1/1
> 0/1286 620396544 0 1/1
> 0/1287 633090048 12722176 1/1
> 0/1293 38301687808 4096 1/1
> 0/1294 636026880 4096 1/1
> 1/1 38972137472 38972137472 ---  <<----- although we''ve
added 300+ GB volume, the total numbers are unchanged
> 
> 
> That can be quite a bit of IO?
To avoid the rescan you can do the assignment atomically with
the creation of the subvol.
Basically if you lay out your future quota/subvol/snapshot when
you create your filesystem, you never have to do a rescan. The
commands are all there for that, but it''s not really easy to do
if you have a complex setup. That part needs a better documentation
and more examples, and also probably a better UI.
Only if you change your mind later on you probably have to rescan.

-Arne
> 
> 
--
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