about btrfs quota issues

about btrfs quota issues

[Shilong Wang]

Hello, Arne

          Steps to reproduce:


                mkfs.btrfs <disk>
                mount <disk> <mnt>
                btrfs quota enable <mnt>

                btrfs sub create <mnt>/sub
                btrfs qgroup create 1/1 <mnt>
                btrfs qgroup assign sub_qgroupid 1/1 <mnt>


                dd if=/dev/zero of=<mnt>/sub/data bs=1M count=1
                sync
                btrfs qgroup show  <mnt>
                #until now, every thing goes well, however, if snapshot happens
                #the quota accounting will go wrong

               btrfs sub snapshot <mnt>/sub <mnt>/snap
               sync
               btrfs qgroup show <mnt>
               #the accounting information of group(1/1) is not expected
               #here exclusive of group (1/1) do not change as expected.

So i took a close look at the algorithm of quota accounting, the 3
steps of algorithm don't
consider some cases like the above example.

In fact, i think you try to put some work on users, especially when
snapshot happens.
It is complex to track all the group's accounting when having
snapshots..See the following
commands.

btrfs sub snapshot -c src_qgroupid:dst_qgroupid  <mnt>
btrfs sub snapshot  -x src_qgroupid:dst_qgroupid <mnt>


Are these commands designed for some cases regarding to
snapshots/subvolume cases?
If so, i think it really confusing and too complex for users to do
such work, is't it?...

BTW, i have a question about the function btrfs_qgroup_inherit(),
when copying exclusive value from src_qgroup to dst_qgroup:

       dst_qgroup->exclusive = src_qgroup->exclusive + level_size

while copying referenced value from src_qgroup to dot_qgroup:

       dst_qgroup->referenced = src_qgroup->referenced -level_size

I can't really figure out...~_~

Thanks,
Wang

Re: about btrfs quota issues

[Wang Shilong]

ping..

> Hello, Arne
> 
>          Steps to reproduce:
> 
> 
>                mkfs.btrfs <disk>
>                mount <disk> <mnt>
>                btrfs quota enable <mnt>
> 
>                btrfs sub create <mnt>/sub
>                btrfs qgroup create 1/1 <mnt>
>                btrfs qgroup assign sub_qgroupid 1/1 <mnt>
> 
> 
>                dd if=/dev/zero of=<mnt>/sub/data bs=1M count=1
>                sync
>                btrfs qgroup show  <mnt>
>                #until now, every thing goes well, however, if snapshot happens
>                #the quota accounting will go wrong
> 
>               btrfs sub snapshot <mnt>/sub <mnt>/snap
>               sync
>               btrfs qgroup show <mnt>
>               #the accounting information of group(1/1) is not expected
>               #here exclusive of group (1/1) do not change as expected.
> 
> So i took a close look at the algorithm of quota accounting, the 3
> steps of algorithm don't
> consider some cases like the above example.
> 
> In fact, i think you try to put some work on users, especially when
> snapshot happens.
> It is complex to track all the group's accounting when having
> snapshots..See the following
> commands.
> 
> btrfs sub snapshot -c src_qgroupid:dst_qgroupid  <mnt>
> btrfs sub snapshot  -x src_qgroupid:dst_qgroupid <mnt>
> 
> 
> Are these commands designed for some cases regarding to
> snapshots/subvolume cases?
> If so, i think it really confusing and too complex for users to do
> such work, is't it?...
> 
> BTW, i have a question about the function btrfs_qgroup_inherit(),
> when copying exclusive value from src_qgroup to dst_qgroup:
> 
>       dst_qgroup->exclusive = src_qgroup->exclusive + level_size
> 
> while copying referenced value from src_qgroup to dot_qgroup:
> 
>       dst_qgroup->referenced = src_qgroup->referenced -level_size
> 
> I can't really figure out...~_~
> 
> Thanks,
> Wang

Re: about btrfs quota issues

[Arne Jansen]

On 10.03.2013 05:21, Shilong Wang wrote:
> Hello, Arne
> 
>           Steps to reproduce:
> 
> 
>                 mkfs.btrfs <disk>
>                 mount <disk> <mnt>
>                 btrfs quota enable <mnt>
> 
>                 btrfs sub create <mnt>/sub
>                 btrfs qgroup create 1/1 <mnt>
>                 btrfs qgroup assign sub_qgroupid 1/1 <mnt>
> 
> 
>                 dd if=/dev/zero of=<mnt>/sub/data bs=1M count=1
>                 sync
>                 btrfs qgroup show  <mnt>
>                 #until now, every thing goes well, however, if snapshot happens
>                 #the quota accounting will go wrong
> 
>                btrfs sub snapshot <mnt>/sub <mnt>/snap
>                sync
>                btrfs qgroup show <mnt>
>                #the accounting information of group(1/1) is not expected
>                #here exclusive of group (1/1) do not change as expected.
> 
> So i took a close look at the algorithm of quota accounting, the 3
> steps of algorithm don't
> consider some cases like the above example.
> 
> In fact, i think you try to put some work on users, especially when
> snapshot happens.
> It is complex to track all the group's accounting when having
> snapshots..See the following
> commands.
> 
> btrfs sub snapshot -c src_qgroupid:dst_qgroupid  <mnt>
> btrfs sub snapshot  -x src_qgroupid:dst_qgroupid <mnt>
> 
> 
> Are these commands designed for some cases regarding to
> snapshots/subvolume cases?

Yes, these commands would have helped you in the above case. You need to
create an empty qgroup and copy the exclusive from there on snapshot
creation.

> If so, i think it really confusing and too complex for users to do
> such work, is't it?...

It is complex. That is why I always point anyone asking to do some work
on btrfs or qgroups to writing an enhanced interface to simplify this
task for the user. I don't think the kernel should handle this.
And that's why I took the effort to write a pdf to explain the
concepts :)
But the current interface is not only complex, it also is very powerful.
You can solve problems with it that no other quota system I know of can
solve.

> 
> BTW, i have a question about the function btrfs_qgroup_inherit(),
> when copying exclusive value from src_qgroup to dst_qgroup:
> 
>        dst_qgroup->exclusive = src_qgroup->exclusive + level_size
> 
> while copying referenced value from src_qgroup to dot_qgroup:
> 
>        dst_qgroup->referenced = src_qgroup->referenced -level_size
> 
> I can't really figure out...~_~

level_size is just a small correction for the space the tree root
occupies. The tree root is never shared between subvolumes.

-Arne

> 
> Thanks,
> Wang

Re: about btrfs quota issues

[Wang Shilong]

Hello,

> On 10.03.2013 05:21, Shilong Wang wrote:
>> Hello, Arne
>> 
>>          Steps to reproduce:
>> 
>> 
>>                mkfs.btrfs <disk>
>>                mount <disk> <mnt>
>>                btrfs quota enable <mnt>
>> 
>>                btrfs sub create <mnt>/sub
>>                btrfs qgroup create 1/1 <mnt>
>>                btrfs qgroup assign sub_qgroupid 1/1 <mnt>
>> 
>> 
>>                dd if=/dev/zero of=<mnt>/sub/data bs=1M count=1
>>                sync
>>                btrfs qgroup show  <mnt>
>>                #until now, every thing goes well, however, if snapshot happens
>>                #the quota accounting will go wrong
>> 
>>               btrfs sub snapshot <mnt>/sub <mnt>/snap
>>               sync
>>               btrfs qgroup show <mnt>
>>               #the accounting information of group(1/1) is not expected
>>               #here exclusive of group (1/1) do not change as expected.
>> 
>> So i took a close look at the algorithm of quota accounting, the 3
>> steps of algorithm don't
>> consider some cases like the above example.
>> 
>> In fact, i think you try to put some work on users, especially when
>> snapshot happens.
>> It is complex to track all the group's accounting when having
>> snapshots..See the following
>> commands.
>> 
>> btrfs sub snapshot -c src_qgroupid:dst_qgroupid  <mnt>
>> btrfs sub snapshot  -x src_qgroupid:dst_qgroupid <mnt>
>> 
>> 
>> Are these commands designed for some cases regarding to
>> snapshots/subvolume cases?
> 
> Yes, these commands would have helped you in the above case. You need to
> create an empty qgroup and copy the exclusive from there on snapshot
> creation.

I am wondering why we need the concept of exclusive.
Maybe it helps to some extent

How about just  kicking it off, since the concepts of exclusive
adds the complexity of btrfs quota.

The worst thing is that i don't think users can master this magic
concept very well.

> 
>> If so, i think it really confusing and too complex for users to do
>> such work, is't it?...
> 
> It is complex. That is why I always point anyone asking to do some work
> on btrfs or qgroups to writing an enhanced interface to simplify this
> task for the user. I don't think the kernel should handle this.
> And that's why I took the effort to write a pdf to explain the
> concepts :)

I don't have any  good ideas about this yet..

> But the current interface is not only complex, it also is very powerful.
> You can solve problems with it that no other quota system I know of can
> solve.
> 
>> 
>> BTW, i have a question about the function btrfs_qgroup_inherit(),
>> when copying exclusive value from src_qgroup to dst_qgroup:
>> 
>>       dst_qgroup->exclusive = src_qgroup->exclusive + level_size
>> 
>> while copying referenced value from src_qgroup to dot_qgroup:
>> 
>>       dst_qgroup->referenced = src_qgroup->referenced -level_size
>> 
>> I can't really figure out...~_~
> 
> level_size is just a small correction for the space the tree root
> occupies. The tree root is never shared between sub volumes.

O.K. I  got it..

Thanks,
Wang

> 
> -Arne
> 
>> 
>> Thanks,
>> Wang
> 

Re: about btrfs quota issues

[Arne Jansen]

On 11.03.2013 14:31, Wang Shilong wrote:
> 
> Hello,
> 
<snip>

>>>
>>> In fact, i think you try to put some work on users, especially when
>>> snapshot happens.
>>> It is complex to track all the group's accounting when having
>>> snapshots..See the following
>>> commands.
>>>
>>> btrfs sub snapshot -c src_qgroupid:dst_qgroupid  <mnt>
>>> btrfs sub snapshot  -x src_qgroupid:dst_qgroupid <mnt>
>>>
>>>
>>> Are these commands designed for some cases regarding to
>>> snapshots/subvolume cases?
>>
>> Yes, these commands would have helped you in the above case. You need to
>> create an empty qgroup and copy the exclusive from there on snapshot
>> creation.
> 
> I am wondering why we need the concept of exclusive.
> Maybe it helps to some extent
> 

It is needed to answer the question 'how many space can I gain but
deleting this subvol or this set of subvolumes?'

> How about just  kicking it off, since the concepts of exclusive
> adds the complexity of btrfs quota.

If you don't need that value, just ignore the tracking error.

> 
> The worst thing is that i don't think users can master this magic
> concept very well.

Normally users don't need very sophisticated scenarios. In fact, they
don't even need higher level quota groups, the basic tracking is
enough. In this case, everything just works as expected for the user.
If you start creating and assigning qgroups manually, prepare to handle
the complexity.

-Arne

> 
>>
>>> If so, i think it really confusing and too complex for users to do
>>> such work, is't it?...
>>
>> It is complex. That is why I always point anyone asking to do some work
>> on btrfs or qgroups to writing an enhanced interface to simplify this
>> task for the user. I don't think the kernel should handle this.
>> And that's why I took the effort to write a pdf to explain the
>> concepts :)
> 
> I don't have any  good ideas about this yet..
> 
>> But the current interface is not only complex, it also is very powerful.
>> You can solve problems with it that no other quota system I know of can
>> solve.
>>
>>>
>>> BTW, i have a question about the function btrfs_qgroup_inherit(),
>>> when copying exclusive value from src_qgroup to dst_qgroup:
>>>
>>>       dst_qgroup->exclusive = src_qgroup->exclusive + level_size
>>>
>>> while copying referenced value from src_qgroup to dot_qgroup:
>>>
>>>       dst_qgroup->referenced = src_qgroup->referenced -level_size
>>>
>>> I can't really figure out...~_~
>>
>> level_size is just a small correction for the space the tree root
>> occupies. The tree root is never shared between sub volumes.
> 
> O.K. I  got it..
> 
> Thanks,
> Wang
> 
>>
>> -Arne
>>
>>>
>>> Thanks,
>>> Wang
>>
> 

Re: about btrfs quota issues

[Wang Shilong]

<snip>

>> The worst thing is that i don't think users can master this magic
>> concept very well.
> 
> Normally users don't need very sophisticated scenarios. In fact, they
> don't even need higher level quota groups, the basic tracking is
> enough. In this case, everything just works as expected for the user.
> If you start creating and assigning qgroups manually, prepare to handle
> the complexity.
> 
Considering this case:

a subvolume related to a user, we limit the space by limiting every subvolume
qgroup, but  we also want to limit  the total space all the users can use. So we create
a parent qgroup(1/1 for example) and assign all subvolume group to this parent group.

The above case is regularly used i think, What's more, many snapshots may be done.
So  i think what i am concerning is not a corner case..

Thanks,
Wang
> 
>> 
>>> 
>>>> If so, i think it really confusing and too complex for users to do
>>>> such work, is't it?...
>>> 
>>> It is complex. That is why I always point anyone asking to do some work
>>> on btrfs or qgroups to writing an enhanced interface to simplify this
>>> task for the user. I don't think the kernel should handle this.
>>> And that's why I took the effort to write a pdf to explain the
>>> concepts :)
>> 
>> I don't have any  good ideas about this yet..
>> 
>>> But the current interface is not only complex, it also is very powerful.
>>> You can solve problems with it that no other quota system I know of can
>>> solve.
>>> 
>>>> 
>>>> BTW, i have a question about the function btrfs_qgroup_inherit(),
>>>> when copying exclusive value from src_qgroup to dst_qgroup:
>>>> 
>>>>      dst_qgroup->exclusive = src_qgroup->exclusive + level_size
>>>> 
>>>> while copying referenced value from src_qgroup to dot_qgroup:
>>>> 
>>>>      dst_qgroup->referenced = src_qgroup->referenced -level_size
>>>> 
>>>> I can't really figure out...~_~
>>> 
>>> level_size is just a small correction for the space the tree root
>>> occupies. The tree root is never shared between sub volumes.
>> 
>> O.K. I  got it..
>> 
>> Thanks,
>> Wang
>> 
>>> 
>>> -Arne
>>> 
>>>> 
>>>> Thanks,
>>>> Wang
>>> 
>> 
> 

Re: about btrfs quota issues

[Arne Jansen]

On 11.03.2013 15:15, Wang Shilong wrote:
> 
> <snip>
> 
>>> The worst thing is that i don't think users can master this magic
>>> concept very well.
>>
>> Normally users don't need very sophisticated scenarios. In fact, they
>> don't even need higher level quota groups, the basic tracking is
>> enough. In this case, everything just works as expected for the user.
>> If you start creating and assigning qgroups manually, prepare to handle
>> the complexity.
>>
> Considering this case:
> 
> a subvolume related to a user, we limit the space by limiting every subvolume
> qgroup, but  we also want to limit  the total space all the users can use. So we create
> a parent qgroup(1/1 for example) and assign all subvolume group to this parent group.
> 
> The above case is regularly used i think, What's more, many snapshots may be done.
> So  i think what i am concerning is not a corner case..

So you just missed to assign the new subvolume to 1/1 by using -i on
snapshot creation.

-Arne

> 
> Thanks,
> Wang
>>
>>>
>>>>
>>>>> If so, i think it really confusing and too complex for users to do
>>>>> such work, is't it?...
>>>>
>>>> It is complex. That is why I always point anyone asking to do some work
>>>> on btrfs or qgroups to writing an enhanced interface to simplify this
>>>> task for the user. I don't think the kernel should handle this.
>>>> And that's why I took the effort to write a pdf to explain the
>>>> concepts :)
>>>
>>> I don't have any  good ideas about this yet..
>>>
>>>> But the current interface is not only complex, it also is very powerful.
>>>> You can solve problems with it that no other quota system I know of can
>>>> solve.
>>>>
>>>>>
>>>>> BTW, i have a question about the function btrfs_qgroup_inherit(),
>>>>> when copying exclusive value from src_qgroup to dst_qgroup:
>>>>>
>>>>>      dst_qgroup->exclusive = src_qgroup->exclusive + level_size
>>>>>
>>>>> while copying referenced value from src_qgroup to dot_qgroup:
>>>>>
>>>>>      dst_qgroup->referenced = src_qgroup->referenced -level_size
>>>>>
>>>>> I can't really figure out...~_~
>>>>
>>>> level_size is just a small correction for the space the tree root
>>>> occupies. The tree root is never shared between sub volumes.
>>>
>>> O.K. I  got it..
>>>
>>> Thanks,
>>> Wang
>>>
>>>>
>>>> -Arne
>>>>
>>>>>
>>>>> Thanks,
>>>>> Wang
>>>>
>>>
>>
> 

Re: about btrfs quota issues

[Wang Shilong]

> On 11.03.2013 15:15, Wang Shilong wrote:
>> 
>> <snip>
>> 
>>>> The worst thing is that i don't think users can master this magic
>>>> concept very well.
>>> 
>>> Normally users don't need very sophisticated scenarios. In fact, they
>>> don't even need higher level quota groups, the basic tracking is
>>> enough. In this case, everything just works as expected for the user.
>>> If you start creating and assigning qgroups manually, prepare to handle
>>> the complexity.
>>> 
>> Considering this case:
>> 
>> a subvolume related to a user, we limit the space by limiting every subvolume
>> qgroup, but  we also want to limit  the total space all the users can use. So we create
>> a parent qgroup(1/1 for example) and assign all subvolume group to this parent group.
>> 
>> The above case is regularly used i think, What's more, many snapshots may be done.
>> So  i think what i am concerning is not a corner case..
> 
> So you just missed to assign the new subvolume to 1/1 by using -i on
> snapshot creation.
> 

When snapshot happens,  the exclusive of 1/1 will go wrong even with  this simple case..

However, thanks very much for your patience and kindly reply ^_^

Thanks, 
Wang

> -Arne
> 
>> 
>> Thanks,
>> Wang
>>> 
>>>> 
>>>>> 
>>>>>> If so, i think it really confusing and too complex for users to do
>>>>>> such work, is't it?...
>>>>> 
>>>>> It is complex. That is why I always point anyone asking to do some work
>>>>> on btrfs or qgroups to writing an enhanced interface to simplify this
>>>>> task for the user. I don't think the kernel should handle this.
>>>>> And that's why I took the effort to write a pdf to explain the
>>>>> concepts :)
>>>> 
>>>> I don't have any  good ideas about this yet..
>>>> 
>>>>> But the current interface is not only complex, it also is very powerful.
>>>>> You can solve problems with it that no other quota system I know of can
>>>>> solve.
>>>>> 
>>>>>> 
>>>>>> BTW, i have a question about the function btrfs_qgroup_inherit(),
>>>>>> when copying exclusive value from src_qgroup to dst_qgroup:
>>>>>> 
>>>>>>     dst_qgroup->exclusive = src_qgroup->exclusive + level_size
>>>>>> 
>>>>>> while copying referenced value from src_qgroup to dot_qgroup:
>>>>>> 
>>>>>>     dst_qgroup->referenced = src_qgroup->referenced -level_size
>>>>>> 
>>>>>> I can't really figure out...~_~
>>>>> 
>>>>> level_size is just a small correction for the space the tree root
>>>>> occupies. The tree root is never shared between sub volumes.
>>>> 
>>>> O.K. I  got it..
>>>> 
>>>> Thanks,
>>>> Wang
>>>> 
>>>>> 
>>>>> -Arne
>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> Wang
>>>>> 
>>>> 
>>> 
>> 
> 

Re: about btrfs quota issues

[Arne Jansen]

On 11.03.2013 15:35, Wang Shilong wrote:
> 
>> On 11.03.2013 15:15, Wang Shilong wrote:
>>>
>>> <snip>
>>>
>>>>> The worst thing is that i don't think users can master this magic
>>>>> concept very well.
>>>>
>>>> Normally users don't need very sophisticated scenarios. In fact, they
>>>> don't even need higher level quota groups, the basic tracking is
>>>> enough. In this case, everything just works as expected for the user.
>>>> If you start creating and assigning qgroups manually, prepare to handle
>>>> the complexity.
>>>>
>>> Considering this case:
>>>
>>> a subvolume related to a user, we limit the space by limiting every subvolume
>>> qgroup, but  we also want to limit  the total space all the users can use. So we create
>>> a parent qgroup(1/1 for example) and assign all subvolume group to this parent group.
>>>
>>> The above case is regularly used i think, What's more, many snapshots may be done.
>>> So  i think what i am concerning is not a corner case..
>>
>> So you just missed to assign the new subvolume to 1/1 by using -i on
>> snapshot creation.
>>
> 
> When snapshot happens,  the exclusive of 1/1 will go wrong even with  this simple case..

Your example does not describe your use case. If you want to account the
snapshot to the user, you also have to assign the snapshot to 1/1. If you
do so, the exclusive will be correct.

-Arne

> 
> However, thanks very much for your patience and kindly reply ^_^
> 
> Thanks, 
> Wang
> 
>> -Arne
>>
>>>
>>> Thanks,
>>> Wang
>>>>
>>>>>
>>>>>>
>>>>>>> If so, i think it really confusing and too complex for users to do
>>>>>>> such work, is't it?...
>>>>>>
>>>>>> It is complex. That is why I always point anyone asking to do some work
>>>>>> on btrfs or qgroups to writing an enhanced interface to simplify this
>>>>>> task for the user. I don't think the kernel should handle this.
>>>>>> And that's why I took the effort to write a pdf to explain the
>>>>>> concepts :)
>>>>>
>>>>> I don't have any  good ideas about this yet..
>>>>>
>>>>>> But the current interface is not only complex, it also is very powerful.
>>>>>> You can solve problems with it that no other quota system I know of can
>>>>>> solve.
>>>>>>
>>>>>>>
>>>>>>> BTW, i have a question about the function btrfs_qgroup_inherit(),
>>>>>>> when copying exclusive value from src_qgroup to dst_qgroup:
>>>>>>>
>>>>>>>     dst_qgroup->exclusive = src_qgroup->exclusive + level_size
>>>>>>>
>>>>>>> while copying referenced value from src_qgroup to dot_qgroup:
>>>>>>>
>>>>>>>     dst_qgroup->referenced = src_qgroup->referenced -level_size
>>>>>>>
>>>>>>> I can't really figure out...~_~
>>>>>>
>>>>>> level_size is just a small correction for the space the tree root
>>>>>> occupies. The tree root is never shared between sub volumes.
>>>>>
>>>>> O.K. I  got it..
>>>>>
>>>>> Thanks,
>>>>> Wang
>>>>>
>>>>>>
>>>>>> -Arne
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Wang
>>>>>>
>>>>>
>>>>
>>>
>>
> 

Re: about btrfs quota issues

[Wang]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 138 bytes --]

OK, thanks.ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ý»k~ÏâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm