Swift keeps total bytes, container, and object count (eventually) up-to-date in 
the account metadata. There are also log processing tools (like slogging - 
http://github.com/notmyname/slogging) that can provide usage information 
(including bandwidth) based on swift logs.

While I think that it's appropriate for swift to generate the usage information 
(via internal processes or log processing), the appropriate place for quotas is 
in whatever system handles the concept of a user (normally the auth system). 
This way quotas are enforced by revoking or limiting access of the auth token.

--John


On Apr 12, 2012, at 11:53 AM, Frederik Van Hecke wrote:

> Hi Kuo,
> 
> One option would be to keep the usage information (num files, num bytes, etc) 
> per container / account in an sqlite DB, just like it is done for account and 
> container info.
> 
> To avoid having to loop through all data at regular intervals (to update the 
> info), additional logic could be added to the api methods to update the 
> sqlite DB's when new files are added, files are deleted, etc. Such approach 
> will require more lines of code, but will be far less stressful on 
> performance.
> 
> (the brute-force approach to loop through it at regular intervals will be 
> hell on performance on large deployments..)
> 
> 
> For data transfer billing based on download / upload amounts, a similar 
> approach could be used.
> 
> If no one else is looking into this, I would certainly be willing to help to 
> help get this started.
> 
> 
> Kind regards,
> Frederik Van Hecke
> 
> T:  +32487733713
> E:  frede...@cluttr.be
> W: www.cluttr.be
> 
> 
> 
> 
> 
> This e-mail and any attachments thereto may contain information which is 
> confidential and/or protected by intellectual property rights and are 
> intended for the sole use of the recipient(s)named above. Any use of the 
> information contained herein (including, but not limited to, total or partial 
> reproduction, communication or distribution in any form) by persons other 
> than the designated recipient(s) is prohibited. If you have received this 
> e-mail in error, please notify the sender either by telephone or by e-mail 
> and delete the material from any computer. Thank you for your cooperation.
> 
> 
> 
> On Thu, Apr 12, 2012 at 17:45, Kuo Hugo <tonyt...@gmail.com> wrote:
> Hi folks , 
> 
> I'm thinking about the better approach to manage "an user" or "an account" 
> space usage quota in swift.
> Is  there any related blueprint or sub-project even an idea around ?
> Any suggestion of benefits to be an external service or to be a middle-ware 
> in swift-proxy ?
> 
> I'm concerning about such feature will reduce the performance of entire Swift 
> environment. 
> 
> Appreciate :>
> 
>   
> 
> -- 
> +Hugo Kuo+
> tonyt...@gmail.com
> +886 935004793
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to