All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arne Jansen <sensille@gmx.net>
To: Wang Shilong <wangsl-fnst@cn.fujitsu.com>
Cc: Jan Schmidt <list.btrfs@jan-o-sch.net>,
	linux-btrfs@vger.kernel.org, dsterba@suse.cz
Subject: Re: [PATCH 1/2] Btrfs: rescan for qgroups
Date: Mon, 15 Apr 2013 12:53:09 +0200	[thread overview]
Message-ID: <516BDC15.8010001@gmx.net> (raw)
In-Reply-To: <516BAA07.3070702@cn.fujitsu.com>

On 15.04.2013 09:19, Wang Shilong wrote:
> Hello Jan,
> 
>> On Mon, April 15, 2013 at 08:08 (+0200), Wang Shilong wrote:
> 
>>> Hello Jan,
>>>
>>>> On Mon, April 15, 2013 at 07:44 (+0200), Jan Schmidt wrote:
>>>>> Thanks, v2 to come.
>>>> Uh, but not immediately. I didn't get tracking of "exclusive" right. That will
>>>> need some time to fix and test.
>>>
>>> 'exclusive' adds the complexity of btrfs qgroup.
>>> So if you send V2. I'd like you add more lines in changelog.
>>
>> Yes, the commit message will be longer as you requested previously. This does
>> not include a complete description on how "exclusive" works. The qgroup pdf
>> explains that.
> 
> 
> Yeah, changelog really helps for newbies(like me ^_^)
> 
>>
>>> Besides, i have a question in my mind.(I have not seen you code)..
>>> When qgroup rescan  will happen?
>>>
>>> 1> when quota is enabled
>>
>> That's what the second patch does, yes. Your patches should be merged in a way
>> that we first create the level 0 qgroups for all subvolumes and then start the
>> rescan, obviously.
>>
>>> 2> if a new qgroup relations is created, rescan should happen?
>>
>> With your patches, there will be no subvolume qgroups missing. For the higher
>> level groups, one needs expert knowledge anyway. I think it's best to leave that
>> decision to the administrator configuring those qgroups.
> 
> 
> IMO, it is better that qgroup rescan automatically if a qgroup relation
> is added.

I think we should leave it as it is, for several reasons:

a) the administrator might want to add multiple configurations. Only after
   the last one a rescan makes sense.
b) the config changes might not make a rescan necessary. For example, you
   could prepare a configuration for newly created or not-yet-existent
   qgroups. In this case, a rescan of the complete filesystem might be
   unnecessary. A rescan might even be harmful, as during the rescan the
   quota is wrong and users can go over quota. Also, a rescan adds significant
   load to the system.

-Arne
> 
> Thank,
> Wang
> 
>>
>>> 2> user call qgroup rescan..
>>
>> Of course, yes.
>>
>> -Jan
>> --
>> 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


  reply	other threads:[~2013-04-15 10:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-05 11:38 [PATCH 0/2] Btrfs: quota rescan for 3.10 Jan Schmidt
2013-04-05 11:38 ` [PATCH 1/2] Btrfs: rescan for qgroups Jan Schmidt
2013-04-05 13:05   ` Josef Bacik
2013-04-10 16:14     ` David Sterba
2013-04-10 16:47   ` David Sterba
2013-04-15  5:44     ` Jan Schmidt
2013-04-15  5:58       ` Jan Schmidt
2013-04-15  6:08         ` Wang Shilong
2013-04-15  6:56           ` Jan Schmidt
2013-04-15  7:19             ` Wang Shilong
2013-04-15 10:53               ` Arne Jansen [this message]
2013-04-05 11:38 ` [PATCH 2/2] Btrfs: automatic rescan after "quota enable" command Jan Schmidt
2013-04-05 12:30   ` Wang Shilong
2013-04-06  6:20 ` [PATCH 0/2] Btrfs: quota rescan for 3.10 Wang Shilong

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=516BDC15.8010001@gmx.net \
    --to=sensille@gmx.net \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=list.btrfs@jan-o-sch.net \
    --cc=wangsl-fnst@cn.fujitsu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.