[
https://issues.apache.org/jira/browse/HDDS-9153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17760166#comment-17760166
]
Ethan Rose commented on HDDS-9153:
----------------------------------
Allocate block does not make any write modifications to space usage. That is
delayed until commit. See the discussion on
https://github.com/apache/ozone/pull/3286 and also the OMAllocateBlockRequest
code. Since we are just reading the quota usage in a write request and write
requests are serialized (nobody can update the quota while we check it in
allocate block) there should be no locks required to check the block's size
against the volume quota. Commit key should be the same, except it will need to
update the bucket space usage as well which already happens.
> Do not require quotas for all buckets in a volume with quota
> ------------------------------------------------------------
>
> Key: HDDS-9153
> URL: https://issues.apache.org/jira/browse/HDDS-9153
> Project: Apache Ozone
> Issue Type: Improvement
> Components: OM
> Affects Versions: 1.4.0
> Reporter: Ethan Rose
> Priority: Major
>
> Currently, if a volume has a quota specified, all buckets created under the
> volume must also have a quota specified. It would be easier for admins to
> manage if this restriction was removed, so that individual buckets in the
> volume did not need their quota set, but their total usage must remain within
> the volume quota.
> Functionally, this should be straightforward. We are already tracking bucket
> space usage for all buckets even if they do not have a quota set. All write
> requests are serialized (including quota updates), and all write requests
> already update the volume space usage as well. We would just need to check
> the updated volume usage against the volume quota if no bucket quota is set.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
