RE: rgw: sticky user quota data on bucket removal
> -Original Message- > From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- > ow...@vger.kernel.org] On Behalf Of Yehuda Sadeh-Weinraub > Sent: Wednesday, December 23, 2015 5:02 PM > To: Paul Von-Stamwitz > Cc: ceph-devel@vger.kernel.org > Subject: Re: rgw: sticky user quota data on bucket removal > > On Wed, Dec 23, 2015 at 3:53 PM, Paul Von-Stamwitz > wrote: > > Hi, > > > > We're testing user quotas on Hammer with civetweb and we're running > > into an issue with user stats. > > > > If the user/admin removes a bucket using -force/-purge-objects options > > with s3cmd/radosgw-admin respectively, the user stats will continue to > > reflect the deleted objects for quota purposes, and there seems to be no > > way to reset them. It appears that user stats need to be sync'ed prior to > > bucket removal. Setting " rgw user quota bucket sync interval = 0" appears > > to > > solve the problem. > > > > What is the downside to setting the interval to 0? > > We'll update the buckets that are getting modified continuously, instead of > once every interval. > So, I presume that this will impact performance on puts and deletes. We'll take a look at the impact on this. > > > > I think the right solution is to have an implied sync-stats during bucket > > removal. Other suggestions? > > > > No, syncing the bucket stats on removal sounds right. > Great. This would alleviate any performance impact on continuous updates. Thanks! > Yehuda > > > All the best, > > Paul > > -- > > To unsubscribe from this list: send the line "unsubscribe ceph-devel" > > in the body of a message to majord...@vger.kernel.org More > majordomo > > info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the > body of a message to majord...@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html
Re: rgw: sticky user quota data on bucket removal
On Wed, Dec 23, 2015 at 3:53 PM, Paul Von-Stamwitz wrote: > Hi, > > We're testing user quotas on Hammer with civetweb and we're running into an > issue with user stats. > > If the user/admin removes a bucket using -force/-purge-objects options with > s3cmd/radosgw-admin respectively, the user stats will continue to reflect the > deleted objects for quota purposes, and there seems to be no way to reset > them. It appears that user stats need to be sync'ed prior to bucket removal. > Setting " rgw user quota bucket sync interval = 0" appears to solve the > problem. > > What is the downside to setting the interval to 0? We'll update the buckets that are getting modified continuously, instead of once every interval. > > I think the right solution is to have an implied sync-stats during bucket > removal. Other suggestions? > No, syncing the bucket stats on removal sounds right. Yehuda > All the best, > Paul > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
rgw: sticky user quota data on bucket removal
Hi, We're testing user quotas on Hammer with civetweb and we're running into an issue with user stats. If the user/admin removes a bucket using -force/-purge-objects options with s3cmd/radosgw-admin respectively, the user stats will continue to reflect the deleted objects for quota purposes, and there seems to be no way to reset them. It appears that user stats need to be sync'ed prior to bucket removal. Setting " rgw user quota bucket sync interval = 0" appears to solve the problem. What is the downside to setting the interval to 0? I think the right solution is to have an implied sync-stats during bucket removal. Other suggestions? All the best, Paul -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
