Btrfs devel - Aug 2013 - btrfs qgroup destroy -> ERROR: unable to create quota group: Device or resource busy

I''m using qgroups and have created a few hundreds of subvolumes in the
past.

It seems that btrfs automatically assigns a qgroup to newly created
snapshot/subvolume, but does not destroy the qgroup when the subvolume
is deleted.

So I''ve tried to destroy the unused qgroups, with mixed success. I was
able to destroy most of them, but some are still failing, i.e.:

# btrfs qgroup destroy 4494 /mnt/lxc1
ERROR: unable to create quota group: Device or resource busy


Note the negative number here, but I also have qgroups with both
positive numbers, which I''m not able to destroy as well:

# btrfs qgroup show /mnt/lxc1 | grep 4494
0/4494 839516160 -69632


qgroup 4494 is not used by any subvolume:

# btrfs sub list /mnt/lxc1 | grep 4494


I did run "btrfs quota rescan" for this filesystem, hoping it will fix
the problem, but it didn''t.


Any advice?


-- 
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 08/09/2013 01:39 PM, Tomasz Chmielewski wrote:
> I''m using qgroups and have created a few hundreds of subvolumes in
the
> past.
> 
> It seems that btrfs automatically assigns a qgroup to newly created
> snapshot/subvolume, but does not destroy the qgroup when the subvolume
> is deleted.
This should be implemented. And will soon.
> 
> So I''ve tried to destroy the unused qgroups, with mixed success. I
was
> able to destroy most of them, but some are still failing, i.e.:
> 
> # btrfs qgroup destroy 4494 /mnt/lxc1
> ERROR: unable to create quota group: Device or resource busy
Just remove qgroup（4494）''s parent qgroup. then it can be removed.
Anyway, i think this is unnecessary.

Thanks,
Wang
> 
> 
> Note the negative number here, but I also have qgroups with both
> positive numbers, which I''m not able to destroy as well:
> 
> # btrfs qgroup show /mnt/lxc1 | grep 4494
> 0/4494 839516160 -69632
> 
> 
> qgroup 4494 is not used by any subvolume:
> 
> # btrfs sub list /mnt/lxc1 | grep 4494
> 
> 
> I did run "btrfs quota rescan" for this filesystem, hoping it
will fix
> the problem, but it didn''t.
> 
> 
> Any advice?
> 
> 
--
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 Fri, 09 Aug 2013 13:56:19 +0800
Wang Shilong <wangsl.fnst@cn.fujitsu.com> wrote:
> > It seems that btrfs automatically assigns a qgroup to newly created
> > snapshot/subvolume, but does not destroy the qgroup when the
> > subvolume is deleted.
> 
> This should be implemented. And will soon.
Great to hear (using 3.11-rc4 now).

> > So I''ve tried to destroy the unused qgroups, with mixed
success. I
> > was able to destroy most of them, but some are still failing, i.e.:
> > 
> > # btrfs qgroup destroy 4494 /mnt/lxc1
> > ERROR: unable to create quota group: Device or resource busy
> 
> Just remove qgroup（4494）''s parent qgroup. then it can be removed.
> Anyway, i think this is unnecessary.
I don''t want to remove the parent qgroup, as it''s in use by
other subvolumes:

# /usr/src/qgroup/btrfs-progs/btrfs qgroup show -c /mnt/lxc1 | grep 4494

0/4494 839516160 18446744073709481984 ---   <------ want to remove only this
one

13/1 2142674944 2142674944
0/3973,0/3974,0/3978,0/3981,0/4355,0/4373,0/4398,0/4400,0/4401,0/4427,0/4448,0/4449,0/4457,0/4458,0/4475,0/4476,0/4487,0/4488,0/4489,0/4490,0/4491,0/4492,0/4493,0/4494,0/4495,0/4496,0/4497,0/4498,0/4499,0/4506,0/4507,0/4518


Parent qgroup 13/1 makes accounting for other qgroups - therefore, I
don''t want to remove it.



BTW, "/usr/src/qgroup/btrfs-progs/btrfs" is from
http://github.com/miaoxie/btrfs-progs.git, to support printing parent/child
qgroup IDs.

Note it shows different values than btrfs from official repository - is that
expected?

# /usr/src/qgroup/btrfs-progs/btrfs qgroup show /mnt/lxc1 | grep 4494
0/4494 839516160 18446744073709481984

# btrfs qgroup show /mnt/lxc1 | grep 4494
0/4494 839516160 -69632

-- 
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 08/09/2013 02:07 PM, Tomasz Chmielewski wrote:
> On Fri, 09 Aug 2013 13:56:19 +0800
> Wang Shilong <wangsl.fnst@cn.fujitsu.com> wrote:
> 
>>> It seems that btrfs automatically assigns a qgroup to newly created
>>> snapshot/subvolume, but does not destroy the qgroup when the
>>> subvolume is deleted.
>>
>> This should be implemented. And will soon.
> 
> Great to hear (using 3.11-rc4 now).
> 
> 
>>> So I''ve tried to destroy the unused qgroups, with mixed
success. I
>>> was able to destroy most of them, but some are still failing, i.e.:
>>>
>>> # btrfs qgroup destroy 4494 /mnt/lxc1
>>> ERROR: unable to create quota group: Device or resource busy
>>
>> Just remove qgroup（4494）''s parent qgroup. then it can be
removed.
>> Anyway, i think this is unnecessary.
> 
> I don''t want to remove the parent qgroup, as it''s in use
by other subvolumes:
> 
> # /usr/src/qgroup/btrfs-progs/btrfs qgroup show -c /mnt/lxc1 | grep 4494
> 
> 0/4494 839516160 18446744073709481984 ---   <------ want to remove only
this one
> 
> 13/1 2142674944 2142674944
0/3973,0/3974,0/3978,0/3981,0/4355,0/4373,0/4398,0/4400,0/4401,0/4427,0/4448,0/4449,0/4457,0/4458,0/4475,0/4476,0/4487,0/4488,0/4489,0/4490,0/4491,0/4492,0/4493,0/4494,0/4495,0/4496,0/4497,0/4498,0/4499,0/4506,0/4507,0/4518
> 
> 
> Parent qgroup 13/1 makes accounting for other qgroups - therefore, I
don''t want to remove it.
Sorry, you must destroy relation between 13/1 and 4494. then you can remove it.

thanks,
Wang
> 
> 
> 
> BTW, "/usr/src/qgroup/btrfs-progs/btrfs" is from
http://github.com/miaoxie/btrfs-progs.git, to support printing parent/child
qgroup IDs.
> 
> Note it shows different values than btrfs from official repository - is
that expected?
> 
> # /usr/src/qgroup/btrfs-progs/btrfs qgroup show /mnt/lxc1 | grep 4494
> 0/4494 839516160 18446744073709481984
> 
> # btrfs qgroup show /mnt/lxc1 | grep 4494
> 0/4494 839516160 -69632
> 
--
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 Fri, 09 Aug 2013 14:08:48 +0800
Wang Shilong <wangsl.fnst@cn.fujitsu.com> wrote:
> > 0/4494 839516160 18446744073709481984 ---   <------ want to remove
> > only this one
> > 
> > 13/1 2142674944 2142674944
> >
0/3973,0/3974,0/3978,0/3981,0/4355,0/4373,0/4398,0/4400,0/4401,0/4427,0/4448,0/4449,0/4457,0/4458,0/4475,0/4476,0/4487,0/4488,0/4489,0/4490,0/4491,0/4492,0/4493,0/4494,0/4495,0/4496,0/4497,0/4498,0/4499,0/4506,0/4507,0/4518
> > 
> > 
> > Parent qgroup 13/1 makes accounting for other qgroups - therefore,
> > I don''t want to remove it.
> 
> Sorry, you must destroy relation between 13/1 and 4494. then you can
> remove it.
So how exactly should I do it? A bit confused on how to proceed.

- remove 13/1, remove 4494

- add 13/1, and add all previous qgroups to it?
0/3973,0/3974,0/3978,0/3981,0/4355,0/4373,0/4398,0/4400,0/4401,....

- run quota scan?


It can''t be right, can it?


-- 
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 08/09/2013 02:42 PM, Tomasz Chmielewski wrote:
> On Fri, 09 Aug 2013 14:08:48 +0800
> Wang Shilong <wangsl.fnst@cn.fujitsu.com> wrote:
> 
>>> 0/4494 839516160 18446744073709481984 ---   <------ want to
remove
>>> only this one
>>>
>>> 13/1 2142674944 2142674944
>>>
0/3973,0/3974,0/3978,0/3981,0/4355,0/4373,0/4398,0/4400,0/4401,0/4427,0/4448,0/4449,0/4457,0/4458,0/4475,0/4476,0/4487,0/4488,0/4489,0/4490,0/4491,0/4492,0/4493,0/4494,0/4495,0/4496,0/4497,0/4498,0/4499,0/4506,0/4507,0/4518
>>>
>>>
>>> Parent qgroup 13/1 makes accounting for other qgroups - therefore,
>>> I don''t want to remove it.
>>
>> Sorry, you must destroy relation between 13/1 and 4494. then you can
>> remove it.
> 
> So how exactly should I do it? A bit confused on how to proceed.
btrfs qgroup remove 4494 13/1 <mnt>

will destroy relation between 4494 and 13/1
Then you can try:

btrfs qgroup destroy 4494 <mnt>

Thanks,
Wang
> 
> - remove 13/1, remove 4494
> 
> - add 13/1, and add all previous qgroups to it?
> 0/3973,0/3974,0/3978,0/3981,0/4355,0/4373,0/4398,0/4400,0/4401,....
> 
> - run quota scan?
> 
> 
> It can''t be right, can it?
> 
> 
--
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 Fri, 09 Aug 2013 14:56:15 +0800
Wang Shilong <wangsl.fnst@cn.fujitsu.com> wrote:
> > So how exactly should I do it? A bit confused on how to proceed.
> 
> btrfs qgroup remove 4494 13/1 <mnt>
> 
> will destroy relation between 4494 and 13/1
> Then you can try:
> 
> btrfs qgroup destroy 4494 <mnt>
Excellent, thanks a lot!

-- 
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, just add my answer for a missing question.
> On Fri, 09 Aug 2013 13:56:19 +0800
> Wang Shilong <wangsl.fnst@cn.fujitsu.com> wrote:
> 
>>> It seems that btrfs automatically assigns a qgroup to newly created
>>> snapshot/subvolume, but does not destroy the qgroup when the
>>> subvolume is deleted.
>> 
>> This should be implemented. And will soon.
> 
> Great to hear (using 3.11-rc4 now).
> 
> 
>>> So I''ve tried to destroy the unused qgroups, with mixed
success. I
>>> was able to destroy most of them, but some are still failing, i.e.:
>>> 
>>> # btrfs qgroup destroy 4494 /mnt/lxc1
>>> ERROR: unable to create quota group: Device or resource busy
>> 
>> Just remove qgroup（4494）''s parent qgroup. then it can be
removed.
>> Anyway, i think this is unnecessary.
> 
> I don''t want to remove the parent qgroup, as it''s in use
by other subvolumes:
> 
> # /usr/src/qgroup/btrfs-progs/btrfs qgroup show -c /mnt/lxc1 | grep 4494
> 
> 0/4494 839516160 18446744073709481984 ---   <------ want to remove only
this one
> 
> 13/1 2142674944 2142674944
0/3973,0/3974,0/3978,0/3981,0/4355,0/4373,0/4398,0/4400,0/4401,0/4427,0/4448,0/4449,0/4457,0/4458,0/4475,0/4476,0/4487,0/4488,0/4489,0/4490,0/4491,0/4492,0/4493,0/4494,0/4495,0/4496,0/4497,0/4498,0/4499,0/4506,0/4507,0/4518
> 
> 
> Parent qgroup 13/1 makes accounting for other qgroups - therefore, I
don''t want to remove it.
> 
> 
> 
> BTW, "/usr/src/qgroup/btrfs-progs/btrfs" is from
http://github.com/miaoxie/btrfs-progs.git, to support printing parent/child
qgroup IDs.
> 
> Note it shows different values than btrfs from official repository - is
that expected?
> 
> # /usr/src/qgroup/btrfs-progs/btrfs qgroup show /mnt/lxc1 | grep 4494
> 0/4494 839516160 18446744073709481984
In fact, group''s exclusive must be less or equal  than it''s
referenced  value, if you find it is not true in official
progs, you can report it!

Here should be expected, because, i don''t cast qgroup''s value
to s64 while
it is stored as u64. I will fix this problem when i rebase my patch-set.

In fact, i doubt whether qgroup''s exclusive helps, because it always
can not
work very well, it requires user to track the value especially snapshoting.

Thanks,
Wang 
> 
> # btrfs qgroup show /mnt/lxc1 | grep 4494
> 0/4494 839516160 -69632
> 
> -- 
> 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