You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bucket quotas, managed with mc quota and subcommands, don't work like the common understanding of the concept of a quota. Since they rely on the object scanner to identify when a bucket is over quota, they cannot be strictly enforced in the way "hard quota" suggests.
The bucket could go over the configured size between scanner passes and mc quota does not have a mechanism to resolve an overage. This feature was intended as a failsafe against something running amok, not a meaningful tool for managing bucket size.
Per @harshavardhana this should be deprecated. It already is in the web docs. In the future, similar functionality will be available as part of Enterprise Catalog.
We has a MinIO Enterprise (old licence, nor lite or plus) and use "mc quota" in a script/cron to set a "default" quota in every bucket that our users create.
We know that isn't a hard quota, but I need it to "force" our users tell us the grouth expectation.
For us, a high quota is better than unlimited quota.
Bucket quotas, managed with
mc quota
and subcommands, don't work like the common understanding of the concept of a quota. Since they rely on the object scanner to identify when a bucket is over quota, they cannot be strictly enforced in the way "hard quota" suggests.The bucket could go over the configured size between scanner passes and
mc quota
does not have a mechanism to resolve an overage. This feature was intended as a failsafe against something running amok, not a meaningful tool for managing bucket size.Per @harshavardhana this should be deprecated. It already is in the web docs. In the future, similar functionality will be available as part of Enterprise Catalog.
Related discussions at:
#5011
#5012
minio/docs#1294
The text was updated successfully, but these errors were encountered: