btrfs qgroup assign -> "ERROR: bad relation requested"

DISCUSSION Tomasz Chmielewski 4 participants 11 messages Jul 28, 2013 – Aug 2, 2013 Btrfs file system

Share & tools

Tomasz Chmielewski

author

2013-07-28 06:51 UTC #0 lore raw

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.

Signature · 2 lines

Tomasz Chmielewski
http://wpkg.org

Wang Shilong

2013-07-28 07:36 UTC #1 lore raw

Hello,

Quoted 25 lines

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

Quoted 6 lines

# 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

Quoted 10 lines

This is Linux 3.10.m

Signature · 6 lines

Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tomasz Chmielewski

author

2013-07-30 12:25 UTC #2 lore raw

Quoted 6 lines · On Sun, 28 Jul 2013 15:36:41 +0800 Wang Shilong <[email protected]>…

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

Signature · 2 lines

Tomasz Chmielewski
http://wpkg.org

Wang Shilong

2013-07-30 13:06 UTC #3 lore raw

Hello,

Quoted 6 lines

Quoted 3 lines · On Sun, 28 Jul 2013 15:36:41 +0800 Wang Shilong <[email protected]>…
Btrfs group assign requires parent's level > children's level, For your example below, you can do like:

Quoted 8 lines

Quoted 3 lines
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

Quoted 6 lines

Signature · 3 lines
-- 
Tomasz Chmielewski
http://wpkg.org

Tomasz Chmielewski

author

2013-07-31 03:46 UTC #4 lore raw

Quoted 11 lines · On Tue, 30 Jul 2013 21:06:32 +0800 Wang Shilong <[email protected]>…

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.

Signature · 2 lines

Tomasz Chmielewski
http://wpkg.org

Tomasz Chmielewski

author

2013-07-31 04:36 UTC #6 lore raw

Quoted 9 lines · On Wed, 31 Jul 2013 12:19:36 +0800 Wang Shilong <[email protected]>…

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

Quoted 1 line

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

Signature · 2 lines

Tomasz Chmielewski
http://wpkg.org

Wang Shilong

2013-07-31 05:14 UTC #7 lore raw

Quoted 23 lines · Tomasz Chmielewski

Quoted 9 lines · On Wed, 31 Jul 2013 12:19:36 +0800 Wang Shilong <[email protected]>…
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.

Quoted 3 lines

# cd btrfs-progs/

# git pull origin master

Oops, i am sorry, here should:

git pull origin qgroup

would you please try it again

Quoted 23 lines

Quoted 1 line
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.

Quoted 8 lines

# 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

Quoted 2 lines

Tomasz Chmielewski

author

2013-07-31 05:39 UTC #8 lore raw

Quoted 7 lines · On Wed, 31 Jul 2013 13:13:37 +0800 Wang Shilong <[email protected]>…

Quoted 1 line
# 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?

Signature · 2 lines

Tomasz Chmielewski
http://wpkg.org

Arne Jansen

2013-08-02 06:30 UTC #10 lore raw

In reply to Tomasz Chmielewski

Quoted 58 lines · Tomasz Chmielewski

Quoted 7 lines · On Wed, 31 Jul 2013 13:13:37 +0800 Wang Shilong <[email protected]>…

Quoted 1 line
# 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

Quoted 1 line

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

Quoted 2 lines