linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arne Jansen <sensille@gmx.net>
To: Wang Shilong <wangshilong1991@gmail.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: about btrfs quota issues
Date: Mon, 11 Mar 2013 15:45:29 +0100	[thread overview]
Message-ID: <513DEE09.10402@gmx.net> (raw)
In-Reply-To: <EDA76C9B-DA11-4909-94CE-01CB8B7D766E@gmail.com>

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


  reply	other threads:[~2013-03-11 14:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-10  4:21 about btrfs quota issues Shilong Wang
2013-03-11 11:04 ` Wang Shilong
2013-03-11 13:16 ` Arne Jansen
2013-03-11 13:31   ` Wang Shilong
2013-03-11 13:38     ` Arne Jansen
2013-03-11 14:15       ` Wang Shilong
2013-03-11 14:21         ` Arne Jansen
2013-03-11 14:35           ` Wang Shilong
2013-03-11 14:45             ` Arne Jansen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2013-03-11 14:59 Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=513DEE09.10402@gmx.net \
    --to=sensille@gmx.net \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wangshilong1991@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).