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@xxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
