On 06/09/11 02:55, Julien Coloos wrote: > Le 05/09/2011 06:12, Greg Banks a écrit : >> >> Julien, I think we agreed on everything else, right? I'm looking >> forward to your next iteration. > After picking your 'uquota_t removal' commit, I also removed it on my > end, and changed the code according to our previous discussions.
Ok, I've read these: commit "Remove uquota_t" commit "Minor code cleanup" commit "Do not mess with mailbox index struct fields upon deleting." commit "When tracking quota usage changes, check all resources." and it all looks fine to me, except that: a) my commit "Make quota -f less racy" is going to cause lots of clashes (sorry!) b) Bron and I both think that your commit "Compute each quota resource upon setting it for the first time." is unnecessary, given that i) quota -f doesn't suck now, and ii) soon, all of the quota-able quantities will be tracked in fields in the index header. So I think we'll need another round, sorry :( Given that the annotations quota is broken and I'll be reimplementing it anyway, you may as well ignore QUOTA_ANNOTSTORAGE in all commits, and leave out the function annotatemore_computequota() for now. We'll use something very much like it for reconstruct later. I'm hoping to be able to pull your next round of changes into my annotate branch before I reimplement the annotation quota in the next few days. > Adding > an helper function which fills a quota_t array with the current messages > usage from mailbox struct made the code a bit cleaner and more generic :) Yes, I'm very pleased with that :) > I still have to look for transferring limits upon DUMP/UNDUMP. And for > the time being, I still kept the quota.sets[] thing (we will see later > if we can do it more smartly). I'm still not convinced we'll need quota.sets[], but I'll play along. Thanks again for your work, and sorry that my annotate branch wasn't quite as stable a base as you first thought :) -- Greg.
